极客时间已完结课程限时免费阅读

26 | 答疑课堂：模块四热点问题解答

26 | 答疑课堂：模块四热点问题解答-极客时间

26 | 答疑课堂：模块四热点问题解答

2019-07-20 刘超 来自北京
《Java性能调优实战》
课程介绍

讲述：李良

时长12:12大小11.17M

你好，我是刘超。
本周我们结束了“JVM 性能监测及调优”的学习，这一期答疑课堂我精选了模块四中 11 位同学的留言，进行集中解答，希望也能对你有所帮助。另外，我想为坚持跟到现在的同学点个赞，期待我们能有更多的技术交流，共同成长。

第 20 讲

很多同学都问到了类似“黑夜里的猫"问到的问题，所以我来集中回复一下。JVM 的内存模型只是一个规范，方法区也是一个规范，一个逻辑分区，并不是一个物理空间，我们这里说的字符串常量放在堆内存空间中，是指实际的物理空间。
文灏的问题和上一个类似，一同回复一下。元空间是属于方法区的，方法区只是一个逻辑分区，而元空间是具体实现。所以类的元数据是存放在元空间，逻辑上属于方法区。

第 21 讲

Liam 同学，目前 Hotspot 虚拟机暂时不支持栈上分配对象。W.LI 同学的留言值得参考，所以这里一同贴出来了。

第 22 讲

非常赞，Region 这块，Jxin 同学讲解得很到位。这里我再总结下 CMS 和 G1 的一些知识点。
CMS 垃圾收集器是基于标记清除算法实现的，目前主要用于老年代垃圾回收。CMS 收集器的 GC 周期主要由 7 个阶段组成，其中有两个阶段会发生 stop-the-world，其它阶段都是并发执行的。
G1 垃圾收集器是基于标记整理算法实现的，是一个分代垃圾收集器，既负责年轻代，也负责老年代的垃圾回收。
跟之前各个分代使用连续的虚拟内存地址不一样，G1 使用了一种 Region 方式对堆内存进行了划分，同样也分年轻代、老年代，但每一代使用的是 N 个不连续的 Region 内存块，每个 Region 占用一块连续的虚拟内存地址。
在 G1 中，还有一种叫 Humongous 区域，用于存储特别大的对象。G1 内部做了一个优化，一旦发现没有引用指向巨型对象，则可直接在年轻代的 YoungGC 中被回收掉。
G1 分为 Young GC、Mix GC 以及 Full GC。
G1 Young GC 主要是在 Eden 区进行，当 Eden 区空间不足时，则会触发一次 Young GC。将 Eden 区数据移到 Survivor 空间时，如果 Survivor 空间不足，则会直接晋升到老年代。此时 Survivor 的数据也会晋升到老年代。Young GC 的执行是并行的，期间会发生 STW。
当堆空间的占用率达到一定阈值后会触发 G1 Mix GC（阈值由命令参数 -XX:InitiatingHeapOccupancyPercent 设定，默认值 45），Mix GC 主要包括了四个阶段，其中只有并发标记阶段不会发生 STW，其它阶段均会发生 STW。
G1 和 CMS 主要的区别在于：
CMS 主要集中在老年代的回收，而 G1 集中在分代回收，包括了年轻代的 Young GC 以及老年代的 Mix GC；
G1 使用了 Region 方式对堆内存进行了划分，且基于标记整理算法实现，整体减少了垃圾碎片的产生；
在初始化标记阶段，搜索可达对象使用到的 Card Table，其实现方式不一样。
这里我简单解释下 Card Table，在垃圾回收的时候都是从 Root 开始搜索，这会先经过年轻代再到老年代，也有可能老年代引用到年轻代对象，如果发生 Young GC，除了从年轻代扫描根对象之外，还需要再从老年代扫描根对象，确认引用年轻代对象的情况。
这种属于跨代处理，非常消耗性能。为了避免在回收年轻代时跨代扫描整个老年代，CMS 和 G1 都用到了 Card Table 来记录这些引用关系。只是 G1 在 Card Table 的基础上引入了 RSet，每个 Region 初始化时，都会初始化一个 RSet，RSet 记录了其它 Region 中的对象引用本 Region 对象的关系。
除此之外，CMS 和 G1 在解决并发标记时漏标的方式也不一样，CMS 使用的是 Incremental Update 算法，而 G1 使用的是 SATB 算法。
首先，我们要了解在并发标记中，G1 和 CMS 都是基于三色标记算法来实现的：
黑色：根对象，或者对象和对象中的子对象都被扫描；
灰色：对象本身被扫描，但还没扫描对象中的子对象；
白色：不可达对象。
基于这种标记有一个漏标的问题，也就是说，当一个白色标记对象，在垃圾回收被清理掉时，正好有一个对象引用了该白色标记对象，此时由于被回收掉了，就会出现对象丢失的问题。
为了避免上述问题，CMS 采用了 Incremental Update 算法，只要在写屏障（write barrier）里发现一个白对象的引用被赋值到一个黑对象的字段里，那就把这个白对象变成灰色的。而在 G1 中，采用的是 SATB 算法，该算法认为开始时所有能遍历到的对象都是需要标记的，即认为都是活的。
G1 具备 Pause Prediction Model ，即停顿预测模型。用户可以设定整个 GC 过程中期望的停顿时间，用参数 -XX:MaxGCPauseMillis 可以指定一个 G1 收集过程的目标停顿时间，默认值 200ms。
G1 会根据这个模型统计出来的历史数据，来预测一次垃圾回收所需要的 Region 数量，通过控制 Region 数来控制目标停顿时间的实现。
Liam 提出的这两个问题都非常好。
不管什么 GC，都会发送 stop-the-world，区别是发生的时间长短。而这个时间跟垃圾收集器又有关系，Serial、PartNew、Parallel Scavenge 收集器无论是串行还是并行，都会挂起用户线程，而 CMS 和 G1 在并发标记时，是不会挂起用户线程的，但其它时候一样会挂起用户线程，stop the world 的时间相对来说就小很多了。
Major Gc 在很多参考资料中是等价于 Full GC 的，我们也可以发现很多性能监测工具中只有 Minor GC 和 Full GC。一般情况下，一次 Full GC 将会对年轻代、老年代、元空间以及堆外内存进行垃圾回收。触发 Full GC 的原因有很多：
当年轻代晋升到老年代的对象大小，并比目前老年代剩余的空间大小还要大时，会触发 Full GC；
当老年代的空间使用率超过某阈值时，会触发 Full GC；
当元空间不足时（JDK1.7 永久代不足），也会触发 Full GC；
当调用 System.gc() 也会安排一次 Full GC。
接下来解答 ninghtmare 的提问。我们可以通过 jstat -gc pid interval 查看每次 GC 之后，具体每一个分区的内存使用率变化情况。我们可以通过 JVM 的设置参数，来查看垃圾收集器的具体设置参数，使用的方式有很多，例如 jcmd pid VM.flags 就可以查看到相关的设置参数。
这里附上第 22 讲中，我总结的各个设置参数对应的垃圾收集器图表。

第 23 讲

我又不乱来同学的留言真是没有乱来，细节掌握得很好！
前提是老年代有足够接受这些对象的空间，才会进行分配担保。如果老年代剩余空间小于每次 Minor GC 晋升到老年代的平均值，则会发起一次 Full GC。
看到这里，我发现爱提问的同学始终爱提问，非常鼓励啊，技术是需要交流的，也欢迎你有任何疑问，随时留言给我，我会知无不尽。
现在回答 W.LI 同学的问题。这个会根据我们创建对象占用的内存使用率，合理分配内存，并不仅仅考虑对象晋升的问题，还会综合考虑回收停顿时间等因素。针对某些特殊场景，我们可以手动来调优配置。

第 24 讲

下面解答 Geek_75b4cd 同学的问题。
我们知道，ThreadLocal 是基于 ThreadLocalMap 实现的，这个 Map 的 Entry 继承了 WeakReference，而 Entry 对象中的 key 使用了 WeakReference 封装，也就是说 Entry 中的 key 是一个弱引用类型，而弱引用类型只能存活在下次 GC 之前。
如果一个线程调用 ThreadLocal 的 set 设置变量，当前 ThreadLocalMap 则会新增一条记录，但由于发生了一次垃圾回收，此时的 key 值就会被回收，而 value 值依然存在内存中，由于当前线程一直存在，所以 value 值将一直被引用。.
这些被垃圾回收掉的 key 就会一直存在一条引用链的关系：Thread --> ThreadLocalMap–>Entry–>Value。这条引用链会导致 Entry 不会被回收，Value 也不会被回收，但 Entry 中的 key 却已经被回收的情况发生，从而造成内存泄漏。
我们只需要在使用完该 key 值之后，将 value 值通过 remove 方法 remove 掉，就可以防止内存泄漏了。
最后一个问题来自于 WL 同学。
内存泄漏是指不再使用的对象无法得到及时的回收，持续占用内存空间，从而造成内存空间的浪费。例如，我在第 03 讲中说到的，Java6 中 substring 方法就可能会导致内存泄漏。
当调用 substring 方法时会调用 new string 构造函数，此时会复用原来字符串的 char 数组，而如果我们仅仅是用 substring 获取一小段字符，而在原本 string 字符串非常大的情况下，substring 的对象如果一直被引用，由于 substring 里的 char 数组仍然指向原字符串，此时 string 字符串也无法回收，从而导致内存泄露。
内存溢出则是发生了 OutOfMemoryException，内存溢出的情况有很多，例如堆内存空间不足，栈空间不足，还有方法区空间不足等都会导致内存溢出。
内存泄漏与内存溢出的关系：内存泄漏很容易导致内存溢出，但内存溢出不一定是内存泄漏导致的。
今天的答疑就到这里，如果你还有其它问题，请在留言区中提出，我会一一解答。最后欢迎你点击“请朋友读”，把今天的内容分享给身边的朋友，邀请他加入讨论。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 8

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
25 | 内存持续上升，我该如何排查问题？
下一篇
27 | 单例模式：如何创建单一对象优化系统性能？
unpreview
 写留言

精选留言(16)

  • 尔冬橙
    2019-09-02
    这是一门神课
    33
  • Nu11PointerEx
    2019-07-31
    刘老师,我有个疑问，文中指出弱引用只能存活再下次GC之前，那假如线程在步骤A设置了threadlocal的值,然后需要在步骤B读出来，但是在AB之间发生了GC,这样会不会导致在步骤B中无法取到对应的值

    作者回复: 如果线程没有销毁，也就是说该key值依然存在引用，即使是弱引用，也不会被回收掉。

    共 4 条评论
    7
  • -W.LI-
    2019-07-20
    老师好!最近正好在看多线程编程指南。有个东西没搞明白。 我自己写了个demo把所有线程都在临界区调用wait方法，wait方法后是sleep方法。我在主线程调用了notifyall()，在临界区内打印了所有线程的状态，notifyall()之前都是waiting，之后都是blocked。出了临界区之后又打印了一次，发现有一个是timed_waiting，别的还是blocked。 从表现来看 notifyall():wait->blocked 调用notifyall()的线程出临界区释放锁锁: 竞争到锁定blocked->runnable，别的还是blocked。 之前老师说notifyall()在出临界区的时候调用比较好，可以防止被唤醒的阻塞状态线程，竞争不到锁再次阻塞。 notifyall是本地方法看不到实现。我想确认下 notifyall的逻辑是:唤醒waiting线程->尝试获取锁->获取不到blocked? 还是:所有waiting状态线程->blocked状态进去锁池队列。(只有在有线程释放锁的时候(出临界区)才会从锁池队列拿一个线程尝试获取锁)。我比较倾向于第二种。没看源码希望老师帮忙解惑下，我特意翻了之前的课在那边也留言了，老师在这回复就好了谢谢老师
    展开

    作者回复: 对的，调用wait之后，会进入到WaitSet队列，当调用notify之后，默认策略是将其从WaitSet队列转至EntryList队列中，再尝试获取锁。

    5
  • Stalary
    2019-07-28
    老师，ThreadLocal使用的时候我存储了一些请求相关的东西，没有使用remove，但是一次请求结束就会自动释放掉了吧，是不是不会出现内存泄漏？还是没太明白出现内存泄漏的场景，线程不都是工作完就会释放掉了吗

    作者回复: 是的，如果我们的线程在使用ThreadLocal的set之后就立刻销毁了，此时之前set的线程的key值通过垃圾回收回收掉，此时value则会存在内存泄漏，而马上又有下一个线程使用ThreadLocal的set，则会清除之前key为null的value，这种情况下是不会出现内存泄漏的。 也就是ThreadLocal的get(),set(),remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。 我们可以使用set之后，sleep下该线程，等待其他请求都一起使用完了set，这样很容易重现内存中的一部分对象无法回收掉。

    共 3 条评论
    4
  • nightmare
    2019-07-20
    老师cms和g1能不能加餐讲详细一点 因为互联网公司 cms和g1问的非常多

    作者回复: 好的，可以考虑。

    3
  • 风轻扬
    2019-09-11
    老师，jdk1.6的substring导致内存泄漏的问题。大字符串截取完之后，我们直接把原大字符串的引用置为null，可以解决这个内存泄漏的问题吗？

    作者回复: 不行，只是原来的引用置为null了，但堆中的字符串对象依然不会被回收掉

    2
  • ヾ(◍°∇°◍)ﾉﾞ
    2019-07-22
    java的垃圾回收使用的是复制算法和标记整理算法，这样对象的内存是变化的吧？那么引用它的栈上的地址也会变掉吗？如果是的话如果hashmap的key如果没有自己实现hashcode的话，是不是就会引起了内存泄漏和程序错乱

    作者回复: 是的，对象的引用也被指向新的地址。

    2
  • Jxin
    2019-07-20
    抛砖引玉了，感谢老师的知无不尽。( ´◔‸◔`)
    2
  • 钱
    2019-09-12
    我们的项目中ThreadLocal使用的蛮多的，使用原因是因为接口调用链长不想修改方法生命，但有些参数要透传就用ThreadLocal来透传参数。 老师能否介绍一下题ThreadLocal的最佳实践？什么场景下会使用？有什么坑需要填？怎么规避风险？

    作者回复: 我们可以读取大部分读写中间件实现源码，可以发现ThreadLocal使用的最为频繁，通常是通过ThreadLocal来获取当前线程的操作类型来实现读写数据源的切换。 在使用完之后实现remove操作，可以规避风险。

    共 3 条评论
    1
  • 风轻扬
    2019-09-11
    老师，jdk1.6的substring的内存泄漏问题。除了升级jdk版本，您有没有其他的办法。我在网上搜了一下，没有看到啥好办法

    作者回复: 升级版本就好了，现在基本都是基于1.8版本了

    共 2 条评论
    1
  • Mq
    2019-07-22
    老师threadlocal的entry不回收是因为value吗，另外我不理解jvm怎么知道我这次gc的时候key就可以回收，会不会出现我多次get的时候有一次就取不到了

    作者回复: 如果线程还存活，此时get是能获取到的，因为还存在强引用。如果线程生命周期已经结束，则ThreadLocal的线程本地变量将会失去引用，我们知道ThreadLocal是成员变量，如果key值没有设置为弱引用，则结束生命周期的线程变量依然会存在ThreadLocal中。 所以，当线程生命周期结束，ThreadLocal的key又为了弱引用，key值就会在垃圾回收期被回收掉。

    2
  • 明翼
    2019-07-22
    超哥，有问题请教下： 1）曾经被问到一个问题，就是java多线程分配内存的时候是如何控制并发冲突的那？ 2）能不能结合代码把java内存创建的过程讲一次，比如成员变量的引用是在哪里分配的（我理解是堆上），堆上还是栈上，临时变量那，通过这种整体的讲解会对我们印象比较深刻。
    共 2 条评论
    1
  • ty_young
    2020-05-02
    老师您好，card table只是老年代才维护的吧，那G1垃圾收集器的RSet也是只维护老年代的引用么(老年代引用年轻代和老年代引用老年代)
    共 1 条评论
  • ty_young
    2020-04-29
    求老师把cms，g1讲得详细点，求加餐
  • asura
    2020-01-24
    每次看完课程，课后评论也会看完。大家看问题的角度不同，思考纬度也不同，着实学到了很多 👍。感谢老师的热情回答！
  • ty_young
    2019-10-27
    真的受益颇多，谢谢老师