我们将我们的软件从 jboss 4.0.5GA 升级到 5.0.1GA，并注意到在一小时左右（或在某些情况下为 90 分钟）后性能急剧下降。
同时，垃圾收集器日志显示次要垃圾收集时间从 0.01 秒跃升至约 1.5 秒，每次清除的堆量从之前的约 400MB 减少到之后的约 300MB。（参见 GC 查看器图 1）
我们认为这些都是同一个根本原因的症状。
jvm设置为：
-server -Xms2048m -Xmx2048m -XX:NewSize=384m -XX:MaxNewSize=384m
-XX:SurvivorRatio=4 -XX:MinHeapFreeRatio=11 -XX:PermSize=80m -verbose:gc
-XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+DisableExplicitGC
-Djava.awt.headless=TRUE -DUseSunHttpHandler=TRUE
-Dsun.net.client.defaultConnectTimeout=25000
-Dsun.net.client.defaultReadTimeout=50000 -Dfile.encoding=UTF-8
-Dvzzv.log.dir=${ercorebatch.log.dir} -Xloggc:${ercorebatch.log.dir}/gc.log
-Duser.language=it -Duser.region=IT -Duser.country=IT -DVFjavaWL=er.core.it
生产环境是 T5220 或 T2000 硬件，具有 32 位 SPARC，运行 Solaris 10 虚拟机。jboss 5.0.1.GA，Java 1.6.0_17
我们建立了一个测试环境，由 2 个相同的盒子组成，运行相同的软件，但一个使用 jboss 4.0.5GA，一个使用 jboss 5.0.1.GA。它们是在配备 4 x 2.2GHz Intel Xeon CPU E5-4620 和 64GB RAM 的 HP ProLiant DL560 Gen8 上运行的 VMWare VM。来宾虚拟机是 4 个 vCPU、4096MB RAM、CentOS 6.4。
我们发现我们可以很容易地在我们的环境中重现该问题。在 4.0.5 上运行的机器运行良好，但在 jboss 5.0.1GA 上我们看到了同样奇怪的 GC 行为。由于我们没有与生产相同的负载量，因此无法在我们的环境中轻松测试性能。
我们不认为这是内存泄漏，因为在每次主要 GC 之后，使用的堆大小都会恢复到相同的大小：
分析天启前后的堆转储，我们发现以下对象的数量不同：
org.jboss.virtual.plugins.context.file.FileSystemContext
在第一个小时里，大约有 8 个，在世界末日来袭后，我们看到 100 到 800 个。
除此之外，堆转储看起来非常相似，顶部对象是 java 或 jboss 对象（即没有应用程序类）
在我们的测试环境中设置-Djboss.vfs.forceVfsJar=true解决了这个问题（即奇怪的 GC 行为消失了），但是当应用于生产时，奇怪的 GC 模式和性能问题仍然存在 - 尽管 GC 时间没有增加太多（到 0.3 秒而不是 1.5 秒）。
在我们的测试环境中，我们随后在 jboss 5.1.0 中部署了相同的软件，并发现与 5.0.1 相同的行为。
所以此时的结论是 jboss 5.x 在 60 / 90 分钟左右发生了一些事情，这对垃圾收集和性能都有影响。
更新：
我们尝试将 Web 服务堆栈升级到 jbossws-native-3.3.1，这解决了我们测试环境中的问题。但是，当部署到下一个测试环境（更接近生产环境）时，问题仍然存在（尽管有所减少）。
更新：
我们通过将 jboss.vfs.cache.TimedPolicyCaching.lifetime 设置为一个非常大的数字来解决这个问题，相当于很多年。
这感觉像是针对 jboss 中的错误的一种解决方法。默认的缓存生命周期是 30 分钟（参见 org.jboss.util.TimedCachePolicy），我们在 60 或 90 分钟后发现了问题。
VFS 缓存实现是 CombinedVFSCache，我认为它在下面使用了 TimedVFSCache。
似乎更好的解决方法是将缓存实现更改为永久缓存，但我们已经在这个问题上浪费了足够的时间，我们的解决方法将不得不这样做。