我正在使用Java 1.8.0_05，Java HotSpot（TM）64位服务器VM 我正在tomcat 8.0.43上运行Java Web应用程序
我最近通过将.war文件拖放到webapps文件夹中来进行部署。
这导致记录以下消息：
Java HotSpot（TM）64位服务器VM警告：CodeCache已满。编译器 已被禁用。 Java HotSpot（TM）64位服务器VM警告：尝试 使用-XX：ReservedCodeCacheSize =增加代码缓存的大小 CodeCache：大小= 245760Kb已使用= 244058Kb max_used = 244079Kb空闲= 1701Kb 界线[...] total_blobs = 48344 nmethods = 47669适配器= 584编译：已禁用 （剩余的连续可用空间不足）
如何查看编译器的当前状态，以查看其是否仍处于禁用状态？
如何启用编译器？我可以简单地重启tomcat吗？
我的应用程序的运行方式似乎没有任何明显的不同（例如，在速度方面）。
有趣的是，将同一应用程序部署到同一服务器时，我没有收到此消息。这就是为什么我想首先只是重新打开编译器，而不是按照消息的建议更改设置（例如：ReservedCodeCacheSize）的原因。
然后，如果问题仍然存在，我可以看到我需要更改的设置。
答案 0 :(得分：3)
解决您的个人问题+ 1条建议：
最简单的方法是启动jvisualvm（已随JDK一起提供），然后检查已使用的代码缓存空间。如果您的CodeCache已满，则JIT编译器将保持禁用状态。检查代码缓存的内存空间：
这将给您概述您的位置。
是的，重新启动肯定会重置缓存状态。重新启动编译器的唯一其他方法是，如果您已经使用正确的参数启动了JVM。 （启用UseCodeCacheFlushing）
JIT优化了代码，但根据您的应用程序和使用方式，您可能看不到任何明显的区别。假设您运行的是web应用程序（由于Tomcat），则网络传输速度或浏览器呈现页面的速度可能要比JIT在核心Java速度方面获得的速度要慢几个数量级。
JIT编译取决于当时正在执行的代码。同一应用程序在JIT工作级别的内部运行可能完全不同。对于低级函数，使用的第三方库越多，您对所有无法控制的线程所发生的事情的把握就越少。
请升级该Java版本。这么早的JDK8版本非常罕见（u_05），而且非常危险。 Java8发行时并不是最稳定的发行版，即使在以后的发行版中，它们也易于复制。 There have been over 1000 bugs已在JDK8中修复。其中许多是直接解决JIT问题。如果您可以控制要与之交谈的环境，请对其进行升级。如果您不这样做，请通知负责人。
答案 1 :(得分：1)
我前一段时间有这个问题，这是我不能告诉你的：
一旦代码缓存已满，编译器就会自动禁用。
会自动重启吗？
不。它将一直处于关闭状态，直到重新启动JVM。
我可以简单地重新启动tomcat吗？
是的。但它可能会再次发生。
我的应用程序的运行方式似乎没有任何明显的不同（例如，在速度方面）。
从长远来看，将存在一些问题，因为可以缓存和优化的代码不再可以在此处编译和存储。
您能做什么？
我将增加CodeCacheSize，启用刷新，并使用VisualVM或其他可以让您查看CodeCache当前状态的应用程序监视应用程序。监视可以帮助您了解是否偶尔达到阈值或是否经常发生。
请记住，CodeCache与Heap是分开的，因此查看HeapSize不会对您有帮助。
编辑： 关于VisualVM，以下是连接到远程JVM的正式步骤：
https://docs.oracle.com/javase/8/docs/technotes/guides/visualvm/applications_remote.html
只需确保启用了JMX，它就可以立即运行。
关于许多应用程序同时运行的问题...是的，从技术上讲，标准Tomcat为所有应用程序启动了一个JVM。缓存空间将被共享。
您还可以通过将VisualVM附加到JVM，取消部署应用程序并检查空间是否已释放来监视这种情况。
您还可以考虑使用Enterprise容器，该容器可让您为每个App创建一个JVM。