我正在查看运行Alfresco的JVM配置选项，主要是this上的Alfresco Wiki文档。其中一个建议是使用JVM标志-Xcomp和-Xbatch。这样做的理由是：
如果您希望Hotspot预编译类，可以添加[-Xcomp和-Xbatch]。但是，这将显着增加服务器启动时间，但会突出显示以后可能会遇到的缺失依赖项。
根据read elsewhere关于-Xcomp和-Xbatch标志的内容，我想知道它们是否确实提供了任何好处。
-Xcomp让HotSpot预先编译所有代码并进行最大程度的优化，从而优先于VM通过系统标准运行获得的任何分析。-Xbatch停止后台编译，这意味着在编译完成之前导致代码被编译的线程。但是，在编译完成后，先前阻塞的线程将不会运行已编译的代码，it will still run the interpreted code。这是Java 6（Mustang）的一个变化 - 在Mustang之前，由于存在-Xbatch标志而被阻止进行编译的线程一旦编译完成就保证在编译的代码中运行。因此，我猜测-Xbatch标志的建议是在旧虚拟机上运行Alfresco的遗留物。有没有人有任何想法？我倾向于摆脱这两面旗帜并依靠虚拟机来解决问题。
我想添加两件事，首先是我还没有访问Alfresco实例来测试这个，其次我不知道什么样的机器托管Alfresco而不是通过寻找在其他配置选项中，它必须是64位VM。尽管如此，我希望社区能够提供一些有用的输入，可能来自一般的HotSpot调整观点。
答案 0 :(得分：23)
一般来说，让HotSpot编译器调整自身总是更好。即使使用服务器VM（-server）也是64位和一些“服务器级”机器的默认设置。
-Xbatch主要用于调试，如您指出的Steve Goldman's blog所述：
因此-Xbatch开关即使在野马前也不是特别有用的开关。它对于jvm开发人员来说有点用处，因为它可以使运行更具可预测性和可重现性。
-Xcomp删除了收集信息以进行高效编译的功能。来自Alex Turner's post：
从性能的角度来看，人们可能会认为-Xcomp是个好主意。但是，它不是！ JIT编译器在编译之前使用这1000次迭代来收集有关如何编译方法以获得最佳效率的信息。 -Xcomp删除了它这样做的能力，因此我们实际上可以看到性能滑动。
如果没有考虑性能，我从未见过使用这些标志来检测缺少的依赖项（and it may not work if some code is still interpreted），所以恕我直言，我会摆脱两者。
答案 1 :(得分：0)
Alfresco是一个企业内容管理。我不确定标志如何影响其性能。然后在同一页面上的一个注释说..
- 但是，这将显着增加服务器启动时间，但会突出显示以后可能遇到的缺失依赖项。 ...
恕我直言，作者并不真正意味着性能提升。他/她将其编写为检查所有依赖关系到位的方法。