我们的应用程序(从数据库角度)由三个部分组成。使用 EJB 的遗留部分，使用 hibernate/spring 的当前应用程序和使用 Mybatis 的第三方库。一个 session 中的数据库操作由 JTA 协调。该应用程序配备了基本的 APM。
我们最近看到了一个非常奇怪的行为，但还无法重现和分析它:我们的应用程序通常在 hibernate 方面执行良好，但在这种情况下，应用程序的所有部分上都有来自其他 session 的一些负载。在此事件期间，APM 报告的 EJB/Spring 部分中执行事务的时间增加了十倍。我们看到执行 EJB/Spring 事务的线程的 CPU 使用率很高，即使事务中执行的实际代码很少。
经过分析，我们了解到这些监控的时间包括我们的业务代码以及Hibernate-Flush所花费的时间。我们还看到实体管理器中元素的数量与完成事务所花费的时间之间的相关性。
我们目前的怀疑是，由于某种原因，同花正在疯狂运行。
有没有人见过这样的事情或者知道可能是什么原因？
最佳答案
答案完全在别处。我们偶然发现了 JDK7/CodeCache Bug，一旦 CodeCache 填满，它会导致 JIT 编译器完全停止编译任何内容。这导致大量代码在解释模式下执行，因此比预期慢很多。
这使得冲水变慢并且看起来像作恶者。
如果您发现应用程序出现奇怪的速度下降，并且仍在运行 JDK7，请查看您的 CodeCache 内存区域。如果它已填满 100%，然后突然下降到 ~50-66& 并且不再增长，那么您就遇到了该错误。
提示:可以在此处找到更详细的解释:JDK7 Application is getting slow after some Uptime
关于java - JTA 上下文中 Hibernate(Flush？)的扩展问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34665425/