我正在开发一个创建大量线程并严重依赖String操作的应用程序
该应用程序一次可以工作24小时，并且需要始终保持响应
我试图将对象的创建保持在最低限度。该应用程序在没有任何配置的情况下运行良好。
但是，如果使用特定的JVM配置有任何优点（或不利），我想知道我自己的知识吗？
请耐心等待，我对JVM / GC配置的主题非常了解：
提前致谢，
答案 0 :(得分：4)
通常，有关调整JVM的最佳建议是不要。除非您遇到与默认设置相关的特定JVM问题，否则请不要管它们。
如果您确实需要摆弄这些设置，我建议您设置一个代表性的测试用例并使用高级探查器，例如JProfiler。
此外，您应该阅读有关HotSpot VM的技术文档，特别是内存管理白皮书，所有这些都可以找到here。
答案 1 :(得分：3)
如果工作正常，那么你就不应该做任何事情。
如果您的应用程序受CPU限制，则不应创建许多线程。 原因是在上下文切换中浪费了大量时间。 字符串操作如果它在内存中则应该只有那些需要的线程
NCPU = UCPU* (1+W/C)
Where NCPU--> Number of CPU
UCPU--> Target CPU Utilization
W-->Wait time
C--> Compute time
因此，对于CPU绑定操作，它应该是max（CPU + 1）线程。
在Java Concurrency in Practice中，还有许多针对并发应用程序定义的测试用例。你可能想检查那些。
答案 2 :(得分：2)
我想知道在使用多线程时是否应该绝对使用任何JVM选项？
没有
我应该配置堆吗？
不，除了将堆大小设置为合理的值（使用-Xmx和-Xms）
我还应该配置GC吗？
不，除非您特别需要“低停顿”。如果您当前正在满足“响应性”目标，则默认吞吐量编译器是最佳选择。如果你没有达到这些目标那么你应该考虑使用CMS或G1 ......但要注意它们会减少暂停但是它们也会降低吞吐量。
我应该将垃圾收集保持在最低限度吗？
没有。这不是一个明智的目标。您的目标是最大化吞吐量，最小化GC不一定能实现这一目标。在很多情况下，生成垃圾比使应用程序做额外工作以避免生成垃圾更有效。 （正如Peter Lawrey所指出的那样，你在编写和维护模式复杂代码方面也得到了额外的开发人员的努力。）
我建议您使用分析器来查看您的应用程序是否花费了大量时间（CPU时间或已用时间）来完成其他生产性工作。如果没有，或者应用程序已经运行得足够快，那么就不要使用JVM选项。
如果您担心您的应用程序将来无法应对增加的负载，那么调整GC无法扩展。更好的选择是调查扩展硬件和/或确定如何在多台机器上完成工作。此外，调整GC以提高当前负载的性能实际上可能导致负载增加时性能更差。 （考虑一下CMS出现的问题，当它无法跟上并被迫做一个完整的世界收集来恢复时。）
最后，拥有大量线程通常是一个坏主意。最好使用少量的工作线程（大致等于处理器/内核的数量），并通过并发队列等方式为它们提供工作。
答案 3 :(得分：2)
我想知道在使用多线程时是否应该绝对使用任何JVM选项？
默认情况下，所有最佳选项都将启用。如果您查看HotSpot VM Options，可以看到相当多的-XX:+，这意味着它们默认开启。
我应该配置堆吗？
可能。但如果可以，我会保留默认设置。
我还应该配置GC吗？
可能。但如果可以，我会保留默认设置。
我应该将垃圾收集保持在最低限度吗？
减少创建的垃圾量需要付出努力。它提供了一些好处。你必须决定什么是你的时间的最佳用途，以及花费多少时间来减少创造的垃圾量。
我总是从内存分析器开始，找到你创建垃圾最多的地方。从列表的顶部开始，而不是尝试调整所有内容，因为这可以确保您以最少的努力获得最大的收益。
答案 4 :(得分：1)
在过去，我遇到了类似的服务器应用程序：大量的字符串操作，字符串创建，并且需要始终非常敏感。该应用程序在默认配置下工作正常，直到遇到高压力情况。您需要启用-XX：+ UseConcMarkSweepGC以进行低暂停，并微调其他参数以确保应用程序行为符合您的需要。这是简短的清单：
-XX：+ CMSParallelRemarkEnabled
-XX：+ CMSScavengeBeforeRemark
-XX：+ UseCMSInitiatingOccupancyOnly
-XX：CMSInitiatingOccupancyFraction = nn
-XX：CMSWaitDuration = 300000
-XX：GCTimeRatio = nn
-XX：+ DisableExplicitGC