『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代码:本地库使用的内存是占用了本地方法栈和本地内存 。
      • 虚拟机和垃圾收集器
    不恰当数据结构导致内存占用过大