day5-jvm

今日总结

黑马jvm 84-107p

JVM

垃圾回收调优

最快的GC就是不发生GC

• 数据是不是太多
  • select *from
• 数据表示是否太臃肿
  • 把对象所有的内容都查出来
  • 对象大小 16字节（基本-包装）
• 是否存在内存泄漏
  • static map，放进去但不移除（static map =new ，new的在堆中，引用在元空间里）
    • 使用软弱引用
    • 第三方缓存实现

新生代gc

• 在新生代new 的内存分配非常廉价
  • TLAB。线程局部分配缓冲区，每个线程用自己私有的伊甸园内存来完成对象的分配
• 新生代死亡对象的回收代价是0
• 大部分对象用过即死
• Minor GC 的时间远远低于Full GC

调优：将新生代调大，但是越大越好吗？

• 小了不好，频繁minor gc，stw多了
• 太大了，老年代就小了，full gc 暂停时间更多
• 一般在25%～50%
• 标记+复制，复制占大头，但是新生代要复制的不多，所以还是尽可能大一点比较好
• 所以：新生代容纳【并发量*请求响应】的数据，因为大部分都会被回收，所以 这样能较少触发mingc
• 幸存区要大到能保留当前活跃对象和需要晋升对象
  • 晋升阈值大了，有的长期存活的一直在消耗性能（复制）。
  • 所以可以让一些长期存活的早点晋升

老年代gc

在cms 中，老年代越大越好，full gc 之后才对老年代调优，否则先尝试调优新生代。
如果fullgc老年代占用内存，可以将内存预设调大1/4～1/3
老年代空间达到多少比例时，就触发full gc

案例

案例1 Full GC 和Minor GC 频繁

原因，来了大量对象，有的对象没活多久也被分配到了老年代

• 解决方案
  • 提高新生代大小和晋升阈值

案例2 请求高峰期发生Full GC，单次暂停时间特别长（CMS）

一般是重新标记阶段，需要扫描新生代和老年代。

• 解决方案
  • 可以在重新标记之前先对新生代对象进行一次垃圾清理

案例3 老年代充裕情况下，发生Full Gc（cms jdk 1.7）

永久代溢出

今日复盘

1. 下午去医院看了外公。
2. 晚上和高中老同学一起吃饭聊天。
3. 明天一定好好学习。