实际上，JVM调优是不得已而为之，有那功夫，好好把烂代码重构一下不比瞎调
JVM强，可以先大致回答一下JVM调优的流程。
JVM调优是一件很严肃的事情，不是拍脑门就开始调优的，需要有严密的分析和监
控机制，大概的一个JVM调优流程图：
在JVM调优方面，我们大致可以采用以下的流程：
1. 监控JVM的性能指标，包括堆内存使用情况、垃圾回收时间、线程数等，以便及时发现问题。
2. 如果发现堆内存溢出的问题，可以通过增加堆内存大小来解决。但是，如果增加堆内存大小不能解决问题，就需要对堆内存进行分析，查找内存泄漏的原因。
3. 如果发现垃圾回收时间过长，可以采取以下措施：增加堆内存大小、调整垃圾回收算法、减少对象的创建等。
4. 如果发现线程数过多，可以采取以下措施：调整线程池大小、优化线程创建和销毁的代码、使用异步编程等。
5. 如果发现代码存在性能瓶颈，可以通过代码优化来提高性能，比如使用缓存、减少对象的创建、减少IO操作等。
H5 有实际调优过吗？
但是，面试官非要问怎么办？可以从处理问题的角度来回答（对应图中事后），这是一个中规中矩的案例：电商公司的运营后台系统，偶发性的引发OOM异常，堆内存溢出。
1、因为是偶发性的，所以第一次简单的认为就是堆内存不足导致，单方面的加大了堆内存从4G调整到8G -Xms8g。
2、但是问题依然没有解决，只能从堆内存信息下手，通过开启了-XX:+HeapDumpOnOutOfMemoryError参数 获得堆内存的dump文件。
3、用JProfiler 对 堆dump文件进行分析，通过JProfiler查看到占用内存最大的对象是String对象，本来想跟踪着String对象找到其引用的地方，但dump文件太大，跟踪进去的时候总是卡死，而String对象占用比较多也比较正常，最开始也没有认定就是这里的问题，于是就从线程信息里面找突破点。
4、通过线程进行分析，先找到了几个正在运行的业务线程，然后逐一跟进业务线程看了下代码，有个方法引起了我的注意，导出订单信息。
5、因为订单信息导出这个方法可能会有几万的数据量，首先要从数据库里面查询出来订单信息，然后把订单信息生成excel，这个过程会产生大量的String对象。
6、为了验证自己的猜想，于是准备登录后台去测试下，结果在测试的过程中发现导出订单的按钮前端居然没有做点击后按钮置灰交互事件，后端也没有做防止重复提交，因为导出订单数据本来就非常慢，使用的人员可能发现点击后很久后页面都没反应，然后就一直点，结果就大量的请求进入到后台，堆内存产生了大量的订单对象和EXCEL对象，而且方法执行非常慢，导致这一段时间内这些对象都无法被回收，所以最终导致内存溢出。
7、知道了问题就容易解决了，最终没有调整任何JVM参数，只是做了两个处理：在前端的导出订单按钮上加上了置灰状态，等后端响应之后按钮才可以进行点击后端代码加分布式锁，做防重处理这样双管齐下，保证导出的请求不会一直打到服务端，问题解决！