有做过 JVM 调优吗？

有做过 JVM 调优吗？

JVM调优是一项严肃的任务，不能凭直觉进行调优，而是需要进行深入的分析和监控。

实际上，JVM调优应该是最后的手段，如果有时间和精力，重构有问题的代码通常比盲目调优更有效。

但是，如果面试官坚持要求回答如何进行JVM调优，可以从问题处理的角度回答。以下是一个常见案例：电商公司的运营后台系统偶尔发生堆内存溢出导致的OOM异常。

1）由于问题是偶发性的，首先可以初步判断是堆内存不足导致的，因此单纯地将堆内存从4G调整到8G（-Xms8g）。

2）然而问题仍未解决，只能从堆内存信息入手，通过启用-XX:+HeapDumpOnOutOfMemoryError参数生成堆内存转储文件。

3）使用JProfiler分析堆转储文件，通过JProfiler发现占用最大内存的对象是String对象。本来想通过跟踪String对象找到引用它的地方，但由于堆转储文件太大，跟踪过程总是卡住。尽管String对象占用的内存较大，但这并不一定是问题所在，因此需要从线程信息入手寻找突破点。

4）通过分析线程，首先找到几个正在运行的业务线程，然后逐一查看这些业务线程的代码。注意到一个方法引起了注意："导出订单信息"。

5）由于订单信息导出可能涉及几万条数据，首先需要从数据库中查询订单信息，然后生成Excel文件。这个过程会产生大量的String对象。

6）为了验证猜想，进行了后台登录测试，结果发现导出订单按钮在前端没有禁用点击的交互，后端也没有防止重复提交的处理。由于导出订单数据需要很长时间，用户可能会发现点击后很久没有反应，然后就不断点击按钮，导致大量请求发送到后端。堆内存中产生了大量订单对象和Excel对象，并且方法执行非常缓慢，导致这些对象在一段时间内无法被回收，最终导致内存溢出。

7）通过定位问题，找到了解决方案，最终没有调整任何JVM参数，而是采取了以下两个措施：

• 在前端导出订单按钮上添加禁用状态，在后端响应之后才允许点击按钮。
• 后端代码添加分布式锁，防止重复提交。

通过这两项措施的双重保障，确保导出请求不会持续发送到服务器，问题得到解决！