- 首页 > 人文 > >
『Java』Java JVM常见面试题：JVM调优案例( 二 )
回收大块堆内存而导致的长时间停顿（可以考虑G1收集器的增量回收）
大内存需要64位Java虚拟机 ， 但是因为64位虚拟机的压缩指针、处理器缓存行容量的额外开销 ， 性能会比32位虚拟机偏低 。
保证应用程序的足够稳定 。 如果发生了OOM ， 堆转储快照的文件太大 ， 信息量很难进行分析 。 甚至无法产生堆转储快照文件 。
多个Java虚拟机 ， 逻辑集群（负载均衡、反向代理）的缺点
- 节点竞争全局的资源（磁盘IO）
- 很难最高效率的利用连接池（分配不均）
- 大量使用本地缓存（各个节点都需要维护自己的缓存 ， 存在内存浪费的情况）
- 优化代码层次：减少大对象的产生 ， 或者不能有批量的、长生存时间的大对象产生 。
- 虚拟机配置：监控观察大对象的大小 ， 设置-XX:PretenureSizeThreshold的大小 ， 来拦截进入对象老年区的机会 。 使其在新生代完成对象的生命周期 ， 并改用CMS收集器 。
- 建立多虚拟机节点的逻辑集群：每个虚拟机分配2G的内存 。
服务器虚拟机进程崩溃
- 场景：基于B/S的MIS系统 ， 双机6实例集群 。
- 问题：运行期间频繁出现集群节点的虚拟机进程自动关闭 。
- 原因：调用了第三方服务导致 ， 由于第三方接口响应时间慢的原因 ， 虽然使用了异步调用的方式 ， 但是会有越来越多等待的线程和Socket连接 ， 导致虚拟机进程崩溃
- 最终总结：使用生产者/消费者模式的消息队列
堆外内存导致的溢出错误
- 场景：websocket实时推送服务
- 问题：服务器不定时抛出内存溢出 。 （加大内存、堆转储快照分析、甚至Eden ， Survivor ， 老年代 ， 方法区的GC频次与时间都无问题）
- 原因：大量的NIO操作使用直接内存导致 。
- 扩展：除了堆和方法区 ， 服务还会占用其他的内存
- 直接内存 ， 如NIO连接 ， 可以设置-XX:MaxDirectMemorySize设置所使用的内存大小 。 即使在OOM的时候 ， 也能产生堆转储快照 。
- 线程堆栈：-Xss调整大小 。
- Socket缓存区：每个Socket连接都需要Receive和Send两个缓存区 。
- JNI代码：本地库使用的内存是占用了本地方法栈和本地内存 。
- 虚拟机和垃圾收集器
不恰当数据结构导致内存占用过大
- 场景：一个后台RPC服务器 ， 使用64位Java虚拟机 ， 内存配置为-Xms4g-Xmx8g-Xmn1g ， 使用ParNew加CMS的收集器组合 。 业务上需要每10分钟加载一个约80MB的数据文件到内存进行数据分析 ， 这些数据会在内存中形成超过100万个HashMap<Long ， Long>Entry ， 在这段时间里面Minor GC就会造成超过500毫秒的停顿 。
