今日总结
黑马jvm 84-107p
JVM
垃圾回收调优
最快的GC就是不发生GC
- 数据是不是太多
- select *from
- 数据表示是否太臃肿
- 把对象所有的内容都查出来
- 对象大小 16字节(基本-包装)
- 是否存在内存泄漏
- static map,放进去但不移除(static map =new ,new的在堆中,引用在元空间里)
- 使用软弱引用
- 第三方缓存实现
- 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)
永久代溢出
今日复盘
- 下午去医院看了外公。
- 晚上和高中老同学一起吃饭聊天。
- 明天一定好好学习。