JVM优化和JVM调优,jvm调优基本思路

　　什么JVM调优：1。您要调谐的内容，请按2。可以调的东西(只能调开放接口，很多东西不一定有开放接口给你调)。综合考虑，只有以下两个方面：

　　方面内存线程方面内存方面JVM需要的总内存。

　　各区块、新生代、生存区、老年的内存分配。

　　选择适当的垃圾收集算法，并控制垃圾收集暂停的次数和时间。

　　解决内存泄露问题，辅助代码优化。

　　内存热点：检查系统中哪些对象数量最多，辅助代码优化。方面死锁检查，辅助代码优化。

　　转储线程详细信息：检查线程的内部操作，查找竞争线程，并协助代码优化。

　　CPU热点：检查系统哪些方法占用大量CPU时间，辅助代码优化。如何调优和监控JVM的状态主要包括内存、线程、代码和I/O。

　　分析结果以确定是否需要优化。

　　调整：垃圾收集算法和内存分配，修改和优化代码。

　　不断重复监测、分析和调整，直到找到最佳平衡点。JVM调优目标GC的时间足够小。

　　GC的数量足够少。

　　把转移到老年的对象减少到最低限度。

　　减少完全垃圾收集的执行时间。

　　完整GC发生的时间间隔足够长。常见的优化策略减少了创建的对象的数量。

　　减少全局变量和大型对象。

　　把新生代和老年的大小调整到最合适。

　　选择合适的GC收集器并设置合理的参数。JVM调优冷思考大部分Java应用不需要服务器端的GC优化。

　　大多数导致GC问题的Java应用程序不是由参数设置错误引起的，而是代码问题。

　　在应用程序上线之前，考虑将机器的JVM参数设置为最优(最合适)。

　　JVM的优化是最后的手段。

　　在实例使用中，分析JVM和优化代码比优化JVM本身要多得多。

　　以下情况通常不需要优化：次要GC执行时间小于50ms。次要GC很少执行，每10秒或更短时间才执行一次。完整的GC执行时间不到1秒。完全GC执行的频率并不频繁，不少于每10分钟一次。JVM调优经验要注意32位和64位操作系统的区别。理论上32位操作系统支持的内存最多是2的32次方4G，而64位操作系统的寻址能力理论上是2的64次方。内存识别的多少和电脑cpu的寻址有关。

　　注意客户端模式和服务器模式的选择。

　　如果GC时间很短，就需要一个较小的堆，而如果GC时间足够短，就需要一个较大的堆。这两者是冲突的，只能平衡。

　　对于JVM堆的设置，最小值和最大值一般可以用-Xms -Xmx来限定。为了防止垃圾收集器在最小值和最大值之间收缩堆，从而导致额外的时间，最大值和最小值通常设置为相同的值。

　　新一代和老一代会按照默认的比例(1:2)分配内存堆，可以通过调整它们之间的比例NewRadio来调整，也可以通过-XX:newSize -XX:MaxNewSize来设置绝对大小。同样，为了防止新一代堆收缩，通常将-xx: max new size设置为相同的大小。

　　合理规划新生代和老年期的规模。如果应用程序中有大量的临时对象，应该选择更大的新一代；持久对象相对较多的，适当增加老年。在做选择的时候，要遵循全GC最小的原则，尽可能让老年缓存常用对象。JVM默认比例是1:2，也是这个道理。

　　通过对应用进行一段时间的观察，可以看出它在高峰期的老年会占用多少内存。在不影响满GC的前提下，可以根据实际情况放大新生代，但至少要给老年预留1/3的成长空间。

　　堆栈的设置：每个线程默认会打开一个1M的堆栈，用来存储堆栈帧、调用参数、局部变量等。对于大多数应用来说，这个默认值太大了，一般256K就够了。在内存相同的情况下，减少每个线程的堆栈可以生成更多的线程。内存泄漏内存泄漏会在系统崩溃前导致一些现象，比如：

　　1.每次垃圾收集的时间越来越长，完整的GC时间也延长到几秒钟。2.全GC的次数越来越多，最频繁的时间不到1分钟。3.老年期内存越来越大，每次满GC后老年期都没有释放内存。4.堆空间在老年时期被占用。内存泄漏的解决方法：一般是基于垃圾回收前后的情况对比，同时基于对象的引用情况分析来辅助寻找泄漏点。

　　当堆栈溢出时，通常会抛出java.lang.StackOverflowError，这通常是由于递归调用没有退出或者循环调用造成的。调优步骤重点介绍调优过程、方法和思路：内存调整、数据库连接调整、内存泄漏查找等。通过JMC记录JFR飞行记录1、检查CPU占用率2、内存分配和使用情况3、垃圾收集执行频率、暂停时间、垃圾收集区域4、文件I/O、socket I/O、检查远程I/O的阻塞时间

　　一般信息、堆使用率、整体CPU利用率和GC暂停时间是三个非常重要的指标。对于Java应用程序，GC暂停时间是最值得注意的指标。

　　通过内存信息，我们可以清楚的看到垃圾收集器的类型，垃圾收集的暂停时间，包括最短暂停时间，平均暂停时间，最长暂停时间，更重要的垃圾收集频率(垃圾收集周期和STW持续时间)。

　　代码分析是Java性能分析的重点。通过代码分析，我们可以清楚地知道系统运行时哪些类和方法被频繁调用。

　　Hotspot方法，通过查看hotspot方法调用栈，可以清楚的了解系统的主要计算资源消耗。

　　通过调用树，我们可以以模块化的方式直观地看到系统的运行状态。

　　通过线程概览报告，我们可以知道CPU利用率(系统利用率，应用JVM利用率)的分布情况，以及活动线程的数量。对于CPU利用率，应用要占用99%的计算资源，而活动线程的数量要控制在一个合理的范围内(视应用而定)。

　　热线程列详细列出了热线程的数量和详细信息。通过细节可以知道线程的执行情况。

　　线程争用是解决应用程序性能的最关键部分。在应用初期，可以通过解决线程争用来初步提升系统性能。上图中的争用是由GC引起的，特别是因为当使用G1时，GC集合的预期暂停时间太短。

　　作为IO系统的基础指标，高IO会导致系统性能急剧下降。避免过多的日志打印和大文件生成可以避免高IO导致的性能问题。

　　通过VisualVM查询实时虚拟机信息。1.查看监控界面，可以看到cup的运行状态，堆的使用情况，类的状态，线程的动态状态。

　　2.看线程，可以看到所有的线程，比如运行、睡眠、等待、停留、监控等。也可以点击右上角的Dump按钮，导出线程的信息，其实就是执行的jstack命令。

　　3.检查采样器，可以采样一段时间的CPU和内存。A. CPU监控：检查热点方法和每个方法占用的CPU时间及其比例。b、内存监控：每个线程分配内存。采样cpu

　　4.添加插件Visual GC，使用Visual GC分析虚拟机的内存区域。

　　a、内存大小分情况B、主要关注点是GC时间的长短和间隔C、查看老Gen和Eden是否连续上升。

　　5.添加插件Tracer，可以监控Heap、PerGen、Cleass、Treads等。

　　总结：JFR飞行记录由JMC记录，实时虚拟机信息由VisualVM监控，并经过调整和优化。

　　调整JVM内存，新生代和age的空间大小，数据库连接池的大小，MySQL的最大连接数等。

　　不断分析调整，直到找到合适的JVM参数配置，找到最合适的参数，将这些参数应用到所有服务器上，并跟进。参考：

　　https://www.cnblogs.com/xifengxiaoma/p/9402263.html

　　https://my.oschina.net/yygh/blog/650507

　　https://www.cnblogs.com/xifengxiaoma/p/9402497.html

　　https://zhuanlan.zhihu.com/p/42541651

　　版权归作者所有：原创作品来自博主肖波，转载请联系作者取得授权，否则将追究法律责任。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。