fix img

专栏/JVM 核心技术 32 讲（完）/19 GC 日志解读与分析（实例分析中篇）.md.html

@@ -288,7 +288,7 @@ CommandLine flags：
 <p>GC 之后呢？年轻代使用量为 17311K ~= 17%，下降了 119107K。堆内存使用量为 360181K ~= 71%，只下降了 82197K。两个下降值相减，就是年轻代提升到老年代的内存量：119107-82197=36910K。</p>
 <p>那么老年代空间有多大？老年代使用量是多少？正在阅读的同学，请开动脑筋，用这些数字算一下。</p>
 <p>此次 GC 的内存变化示意图为：</p>
-<p><img src="assets/13640c30-63ac-11ea-a283-8f19fc193c49" alt="4438116.png" /></p>
+<p><img src="assets/13640c30-63ac-11ea-a283-8f19fc193c49" alt="png" /></p>
 <p>哇塞，这个数字不得了，老年代使用量 98% 了，非常高了。后面紧跟着就是一条 Full GC 的日志，请接着往下看。</p>
 <h4><strong>Full GC 日志分析</strong></h4>
 <p>实际上这次截取的年轻代 GC 日志和 FullGC 日志是紧连着的，我们从间隔时间也能大致看出来，<code>1.067 + 0.02secs ~ 1.091</code>。</p>
@@ -484,7 +484,7 @@ CommandLine flags：
 <p>参照前面年轻代 GC 日志的分析方法，我们推算出来，上面的 CMS Full GC 之后，老年代的使用量应该是：445134K-153242K=291892K，老年代的总容量 506816K-157248K=349568K，所以 Full GC 之后老年代的使用量占比是 291892K/349568K=83%。</p>
 <p>这个占比不低。说明什么问题呢？ 一般来说就是分配的内存小了，毕竟我们才指定了 512MB 的最大堆内存。</p>
 <p>按照惯例，来一张 GC 前后的内存使用情况示意图：</p>
-<p><img src="assets/7fad0940-63ad-11ea-9c08-6f91e6eaabb6" alt="3110993.png" /></p>
+<p><img src="assets/7fad0940-63ad-11ea-9c08-6f91e6eaabb6" alt="png" /></p>
 <p>总之，CMS 垃圾收集器在减少停顿时间上做了很多给力的工作，很大一部分 GC 线程是与应用线程并发运行的，不需要暂停应用线程，这样就可以在一般情况下每次暂停的时候较少。当然，CMS 也有一些缺点，其中最大的问题就是老年代的内存碎片问题，在某些情况下 GC 会有不可预测的暂停时间，特别是堆内存较大的情况下。</p>
 <blockquote>
 <p>透露一个学习 CMS 的诀窍：参考上面各个阶段的示意图，请同学们自己画一遍。</p>