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. 明天一定好好学习。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值