【JVM知识汇总-6】JVM性能调优

【JVM知识汇总-1】JVM内存模型【JVM知识汇总-2】HotSpot虚拟机对象【JVM知识汇总-3】垃圾收集策略与算法【JVM知识汇总-4]HotSpot垃圾收集器【JVM知识汇总-5】内存分配与回收策略【JVM知识汇总-6】JVM性能调优【JVM知识汇总-7】Class文件结构【JVM知识汇总-8】类【JVM知识汇总】-9】类加载的过程【JVM知识总结-10】类加载器将程序部署在高性能硬件上。目前有两种方式：使用64位JDK来使用大内存和使用几个32位的64位JDK来管理内存。堆内存变大后，垃圾回收的频率虽然降低了，但是每次垃圾回收的时间变长了。如果堆内存是14G，每次FullGC会持续几十秒。如果频繁出现FullGC，对于一个网站来说是难以承受的。对于用户交互性强、暂停时间敏感的系统，能够为Java虚拟机分配大堆的前提是保证应用的FullGC频率控制得足够低，至少低到可以不会打动用户。可能出现的问题：内存回收导致长时间停顿。现阶段64位JDK的性能普遍低于32位JDK。需要保证程序足够稳定，因为如果这样的应用产生堆溢出，几乎不可能产生heapdumpsnapshot（因为要产生超过10GB的dumpfile），即使产生了snapshot，它无法分析。同一个程序在64位JDK中的内存消耗普遍大于32位JDK，这是由指针扩展、数据类型对齐填充等因素造成的。使用32位JVM建立逻辑集群在一台物理机上启动多个应用服务器进程，为每个服务器进程分配不同的端口，然后在前端搭建负载均衡器以反向代理的形式分发访问请求.考虑到在物理机上建立逻辑集群的目的只是尽可能利用硬件资源，不需要关心状态保存、热传输等高可用需求，也不需要保证每个虚拟机进程都有绝对负载均衡，所以使用没有session复制的affinitycluster是个不错的选择，而且没必要保证每个虚拟机进程都有绝对的负载均衡，所以使用affinity是个不错的选择没有会话复制的集群。我们只需要保证集群具有亲和性，即balancer总是会按照一定的规则算法（一般是根据SessionID分配），将固定的用户请求分配给固定的集群节点进行处理。可能出现的问题：尽量避免节点竞争本地资源，比如磁盘竞争。如果每个节点同时访问某个磁盘文件，可能会导致IO异常。难以高效利用资源池，比如连接池，一般在Node恢复自己独立的连接池，可能会导致部分节点池已满，而其他节点仍有空间；每个节点都受32位内存的限制。使用大量本地缓存的应用程序会在逻辑集群中引起更大的问题。内存的浪费，因为每个逻辑节点都有一个缓存，这个时候，可以考虑把本地缓存改成集中缓存。调优案例分析和实际场景描述一个使用32位JDK和4G内存的小系统。测试过程中发现服务器时不时抛出内存溢出异常。添加-XX:+HeapDumpOnOutOfMemoryError（添加该参数后，堆内存溢出会输出异常日志），但再次溢出时，不会产生相关日志。分析在32位的JDK上，1.6G分配给堆，另外一些内存分配给JVM。最大直接内存只能分配在剩余的0.4G空间中。如果使用NIO，JVM会在JVM内存之外分配内存空间，一定要注意“直接内存”不足时会出现内存溢出异常。直接内存的回收过程虽然直接内存不是JVM的内存空间，但是它的垃圾回收也是由JVM负责的。当进行垃圾回收时，虽然虚拟机会回收直接内存，但是直接内存无法像新生代和老年代那样发现空间不足时通知垃圾回收器进行垃圾回收。只能等老年代满了。FullGC，然后“顺便”帮助它清理内存中的废弃对象。否则只能等到抛出内存溢出异常，先捕获，然后在catch块中调用System.gc()。如果虚拟机还是不听，就只能看着堆里还有很多空闲内存，但是又得抛出内存溢出异常。