小编use*_*206的帖子

我想知道这两个Executors类的方法有什么区别？我有一个Web应用程序,我每100毫秒检查一些数据,这就是为什么我使用scheduleWithFixedDelay方法的调度程序.我想知道在这种情况下我应该使用哪种方法(newScheduledThreadPool或newSingleThreadScheduledExecutor)？我还有一个问题 - 在VisualVM中我监视我的Glassfish服务器我注意到我有一些处于PARK状态的线程 - 例如:

java.lang.Thread.State: WAITING
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for <3cb9965d> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

是否有可能这些线程与调度程序连接,因为我不知道还有什么会创建它们？这些线程永远不会被破坏,所以我担心这会导致一些麻烦.这是一个截图(新的Thread-35将在15分钟内创建,依此类推......):

在尝试了多种不同的 JVM GC 设置并进行了大量测试后，我遇到了长时间主要 GC 暂停的问题，现在我正在使用 G1GC JVM GC 进行测试。除此之外，我还使用性能监视器收集数据，并且只有正在运行的应用程序（除了系统服务，...）是包含我的应用程序的 GlassFish 服务器。我在性能监视器日志中没有发现任何奇怪的东西（CPU 使用率约为 5-10%，当 GC 发生时，它会变得更高一点，内存使用率约为 60%，...）。现在是测试的第五天，我注意到以下内容：

直到第二次主要（混合）GC 发生时，一切都很好（次要 GC 大约 20 毫秒长，GC 性能为 160000M/s，...）。第二次主要 GC 花费了大约 2 秒（长 - 第一次花费了 150 毫秒，但并不重要），之后次要 GC 比之前长得多（参见图中的灰线，代表次要（年轻）GC 的持续时间）和 GC 性能只有12000M/s并且还在下降。我想知道为什么在第二次主要 GC 之后会发生这种情况，即使没有其他应用程序正在运行并且 CPU/内存使用情况与以前相同。我不知道这里发生了什么。我还有一个问题 - 我在不同的 PC 上运行相同的测试，这些 PC 的 RAM 较少，处理器较旧，GC 性能约为 5000M/s（次要 GC 约为 50-100ms），我认为这是正常的，因为处理器较差和更少的内存。奇怪的是，运行 3 天后，Major GC 还没有发生，而且即使设置相同，老年代的增长也比这里慢得多。为什么增长速度慢得多（这里两天大约 150MB，第二台 PC 三天 80MB）？感谢您的所有回答，我不知道为什么 GC 表现如此异常（首先它工作正常，然后性能恶化）。

编辑：这是在 GCViewer 中导入的完整 GC 日志文件以及来自 GCViewer 的事件详细信息统计信息：

第三次主要 GC 的日志：

2015-06-08T08:09:13.123+0200: 572815.533: [GC concurrent-root-region-scan-start] …