这篇文章是关于最近的性能调整练习的。 与往常一样，这些开始于关于症状的模糊表述。 这次，魔鬼采取了“应用程序速度慢，我们无法访问源代码的形式。 我们有什么改善情况的选择”。
对该应用程序进行仔细研究后发现，它由捆绑在一起的几个批处理作业组成。 深入研究“绩效”标准表明，执行特定工作所花费的时间过长。 稍后再仔细检查，我得到了一个可衡量的目标。 我需要从特定的作业运行时间中抽出两分钟，以适应预先分配的时间窗口。
陷入困境的应用程序是一个看起来非常无辜的小型JAR文件。 幸运的是，这也捆绑了负载测试。
在打开GC日志记录的情况下运行该应用程序（ -XX：+ PrintGCTimeStamps -Xloggc：/path-to/gc.log -XX：+ PrintGCDetails ）并快速查看日志，这是优化的第一个目标。 累积的GC暂停时间总计为三分半钟，暗示我可能会有机会。
在这种情况下，他可以使用几种工具，其中一些简单明了：
- 修改堆/ permgen的大小
- 更改GC算法
- 配置内存区域之间的比率
我采取了改变堆大小的方法。 除了幸运的猜测外，它还基于最近学到的有关实时数据集大小和建议堆大小之间的相关性的课程。 从GC日志中，我还注意到该应用程序的实时数据集约为240m。 因此，根据我最近获得的知识，此应用程序堆的最佳结合点在720至960m之间。
但是在配置中，我发现-Xmx设置为仅300m。 稍微调整一下参数，我再次运行测试，结果如下：
| 堆大小 | 总GC暂停时间 | 通量 |
|---|---|---|
| 300m | 207.48秒 | 92.25％ |
| 384m | 54.13秒 | 97.97％ |
| 720m | 20.52秒 | 99.11％ |
| 1,440m | * 11.37秒 | * 99.55％ |
*表示此配置在运行期间未触发Full GC。
现在，如果您查看结果，可能会将结果转换为“越大越好”。 如果仅以毫秒为单位进行测量，那的确是正确的。 如果成功标准之一与金钱有关，那么可能就不那么容易了。 在大型部署中将数百或数千台这些机器放在一起，您可能会单单在电费账单上就感到讨厌。
除此之外，本文是性能调优教科书中的教科书案例。 如果您有可衡量的目标，并且可以衡量结果而不是猜测，那么您将成功。 如果我被迫在没有明确目标或负载测试能力的情况下跳入，那么我仍然会调整配置的随机位。
翻译自: https://www.javacodegeeks.com/2014/03/allocating-memory-for-the-jvm-a-case-study.html
