我创建了一个多线程应用程序，它使用相同的 ScheduledExecutorService(方法 scheduleAtFixedRate 和 10 个线程的固定线程池)执行不同的任务。然而，除了一个主任务(不要与主线程混淆!)之外的所有线程大部分时间都处于 hibernate 状态，直到有用户输入。主任务和其他(用户输入)线程之间共享的数据由同步块(synchronized block)中的锁对象保护。
主任务以相当高的频率执行重复任务，比方说 25 赫兹(即 40 毫秒的周期)，及时执行此任务很重要。通常情况也是如此，但不幸的是并非总是如此。其他“不错”的应用程序也在同一台计算机上运行 (Linux OP)，但 CPU<<100%。
在 60 分钟的测量期间(即 90000 个样本)，在大约 50 个案例中，两个连续样本之间的实际周期 >= 60 毫秒，在一些非常糟糕的案例中，其中大约 30 个周期超过 100 毫秒(在时间上彼此相当接近，以秒为单位)，周期在 1000 到 2300 毫秒之间。测量期间没有用户输入。查看数据日志，似乎很明显在这些时间间隔内某些东西阻止了执行器执行其工作，因为它们之后通常会“ catch ”执行器，即在 2 或 3 毫秒内来自应用程序的多个日志。
我尝试过在每次执行任务时定期进行垃圾回收，但(至少从短期来看)它似乎只会让事情变得更糟。我还测量了任务的执行时间。它主要在 1 毫秒左右，它不应该导致 Executor 崩溃(或者应该吗？)。这里也有偏差，偶尔在 100 毫秒左右，但它们只能解释不到 50% 的延迟。我尝试寻找 TaskRejectedExceptions，但一无所获。
所以我现在的问题基本上是:随着时间的推移，我对 ScheduledExecutorService 有什么期望？这是否可能是线程问题，尽管在这些情况下应该只运行主任务？什么可能导致 ScheduledExecutor 暂时停止执行，只是用它的“追赶”数据淹没日志，有什么方法可以控制这种烦人的行为吗？这是否与我的 JVM 只是一个没有实时优先级功能的普通 JVM 这一事实有关？非常感谢任何关于从哪里开始挖掘的帮助、想法或理论!
最佳答案
根据定时器documentation ，您的情况似乎完全正常:
In fixed-rate execution, each execution is scheduled relative to the scheduled execution time of the initial execution. If an execution is delayed for any reason (such as garbage collection or other background activity), two or more executions will occur in rapid succession to "catch up." In the long run, the frequency of execution will be exactly the reciprocal of the specified period (assuming the system clock underlying Object.wait(long) is accurate).
事实是 scheduleAtFixedRate() 不能保证执行会在它应该开始的时候准确开始，但只能保证从长远来看的频率。 实际上，我不确定是否有办法使用 Java 来实现这一点。
关于Java ScheduledExecutorService - 需要有关实时性能问题的建议，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9120874/