应采用什么策略来确保 JVM 内存管理始终快速？
应采用什么策略来确保 JVM 内存管理始终快速？
我通过 Timer#scheduleAtFixedRate() 定期运行一个方法，每 10 秒一次，定期方法通常需要 5 到 50 毫秒，但有时会更长。除了这个周期性方法之外，应用程序没有其他事情可做。有时会超过10秒。由于应用程序的性质不会或不应该导致所用时间的较大变化，我认为这种变化是由于垃圾收集造成的。如何才能将垃圾收集时间始终控制在 10 秒以内？
周期性方法在几个小时内每 10 秒建立一个列表并在图表上绘制点。在几个小时的时间段结束时，它会对整个时间收集的所有数据进行一些二进制序列化。
我尝试使用 System.gc() 结束周期性方法，但方法运行时间仍然超过 10 秒。运行 10 秒后，将返回到 5 毫秒运行时间方法。然后慢慢地需要更长的时间，直到经过大约10秒的时间。然后重复循环。我也见过其他模式。
您可能想知道如果该方法花费的时间比 scheduleAtFixedRate() 中设置的时间长，会发生什么情况。发生的情况是下一次调用被延迟（没有中止正在进行的方法，也没有尝试使用另一个线程来遵守计划）。如果运行速度持续缓慢，我想只会出现大量积压。幸运的是，较长的运行时间只是偶尔出现，大多数都在 5 到 50 毫秒之间。不过，我不希望这些长时间运行，因为它们破坏了周期性。
一个快速解决方法是将我的周期更改为 15 秒，从而确保该周期大于最坏情况下经过的时间。这只是一个解决方法。在垃圾收集中获得一致性会好得多。
What strategies should be employed to ensure that JVM memory management is always quick?
I run a method periodically, every 10 seconds, via Timer#scheduleAtFixedRate() and the periodic method takes 5 to 50 milliseconds usually but occasionally much longer. The application does not have anything else to do but this periodic method. Sometimes it exceeds 10 seconds. Since the nature of the application does not or should not cause large variability in the elapsed time, I think the variability is due to garbage collection. How can I keep garbage collection well under 10 seconds always?
The periodic method builds up lists and plots points on graphs every 10 seconds for several hours. At the end of the several hour period it does some binary serializations of all data that was collected the whole time.
I tried ending the periodic method with a System.gc() but I still get method runs that take more than 10 seconds. After the 10 second run, it will go back to 5 millisecond elapsed time method runs. Then it will gradually take longer, until there is an elapsed time of about 10 seconds. Then the cycle repeats. I've seen other patterns as well.
You might wonder what happens if the method takes longer than the period that is set in scheduleAtFixedRate(). What happens is that the next invocation is delayed (there is no aborting of an in progress method nor an attempt to stick to the schedule by using another thread). If slow runs persist I guess there would simply be a big backlog. Fortunately the long elapsed time runs are just occasional and the majority are just between 5 and 50 milliseconds. Still, I don't want these long elapsed time runs because they ruin the periodicity.
A quick fix is to change my period to 15 seconds, thereby ensuring the period is greater than the worst case elapsed time. This would only be a work-around. It would be far better to get consistency in garbage collection.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
要通过权衡效率来减少运行时间，请在 java 调用命令行上使用 JVM 选项 -Xincgc。
To reduce elapsed times by trading off efficiency use the JVM option -Xincgc on your java invocation command line.