高并发服务优化篇：详解一次由读写锁引起的内存泄漏

高并发服务优化篇：详解一次由读写锁引起的内存泄漏

作者：Coder的技术之路 2021-08-02 13:08:56

云计算

虚拟化 JVM相关的异常，一直是一线研发比较头疼的问题。因为对于业务代码，JVM的运行基本算是黑盒，当异常发生时，较难直观的看到和找到问题所在，这也是我们一直要研究其内部逻辑的原因。

创新互联服务项目包括海曙网站建设、海曙网站制作、海曙网页制作以及海曙网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，海曙网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到海曙省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

JVM相关的异常，一直是一线研发比较头疼的问题。因为对于业务代码，JVM的运行基本算是黑盒，当异常发生时，较难直观的看到和找到问题所在，这也是我们一直要研究其内部逻辑的原因。

本篇就由一个近期线上JVM内存泄漏的例子，带大家强行分析一波~

Part1 线上服务器报警了

某天，同事来找我帮忙，原来是某系统毫无征兆的来了一连串报警，一波机器的老年代内存占用率超过阈值~

1.1先看表现

老年代内存占用

可以看到，在7月中旬之前，内存占用还是比较正常的，每次GC都可以回收掉很大一部分的老年代对象。

而中旬之后，老年代内存一直缓慢增长而无法释放。很明显，应该是对象没法被正常回收导致。

内存泄漏了~

1.2 怎么办呢

如果是刚上线的项目爆出了此类问题，因为影响面比较小，可以直接先回滚代码，止血为第一要务。

不过，这个项目明显已经上线N多天，中间还不知道上过多少需求，而且，既然流量近期有上涨导致问题出现，说明，已经对客开流量了。

回滚是不可能了，抓紧时间定位问题，上线修复吧。

Part2 定位问题

一般的步骤：

  • 拿到dump文件
  • 用MAT等工具，找出内存占用过多的异常对象，以及引用关系
  • 分析异常对象关联代码的可能问题

不过，因为这次dump下来的文件十多G，太大的，MAT基本无能为力，只能打印出来人工分析了

2.1 定位问题代码

jmap结果查看

很幸运，异常对象非常明显。Point对象和GeoDispLocal对象，居然多达好几百万实例数，那就先看下代码中这两个对象是怎么用的。

  
 
 
 
    
   
  
  
  
  1. private static final CacheMap> NEAR_DISTRICT_CACHE = new CacheMap>(3600 * 1000, 1000);
    2. 
   
  
  
  
  2. 
   
  
  
  
  3. private static final CacheMap LOCAL_POINT_CACHE = new CacheMap(3600 * 1000, 6000);
    4.

都是被存放在本次缓存CacheMap中(内存泄漏的一个常见原因，就是因为被静态集合持有，无法回收导致)，而dump文件中的CacheMap.Entry也是非常高的。

CacheMap就是我们的第一优先怀疑对象了。先看下这个缓存类是怎么回事：

  
 
 
 
    
   
  
  
  
  1. ublic class CacheMap {
    2. 
   
  
  
  
  2.     private final long expireMs;
    3. 
   
  
  
  
  3.     private LRUMap> valueMap;
    4. 
   
  
  
  
  4.     //其他略
    5. 
   
  
  
  
  5. }
    6.

内部依赖一个带LRU功能的map，怎么实现的呢:

  
 
 
 
    
   
  
  
  
  1. public class LRUMap extends LinkedHashMap {
    2. 
   
  
  
  
  2.     private static final long serialVersionUID = 1L;
    3. 
   
  
  
  
  3.     private final int maxCapacity;
    4. 
   
  
  
  
  4.     // 这个map不会扩容
    5. 
   
  
  
  
  5.     private static final float LOAD_FACTOR = 0.99f;
    6. 
   
  
  
  
  6.     private final ReadWriteLock lock = new ReentrantReadWriteLock();
    7. 
   
  
  
  
  7. 
   
  
  
  
  8.     public LRUMap(int maxCapacity) {
    9. 
   
  
  
  
  9.         super(maxCapacity, LOAD_FACTOR, true);
    10. 
   
  
  
  
  10.         this.maxCapacity = maxCapacity;
    11. 
   
  
  
  
  11.     }
    12. 
   
  
  
  
  12. 
   
  
  
  
  13.     @Override
    14. 
   
  
  
  
  14.     protected boolean removeEldestEntry(java.util.Map.Entry eldest) {
    15. 
   
  
  
  
  15.         return size() > maxCapacity;
    16. 
   
  
  
  
  16.     }
    17. 
   
  
  
  
  17. 
   
  
  
  
  18.     @Override
    19. 
   
  
  
  
  19.     public V get(Object key) {
    20. 
   
  
  
  
  20.         try {
    21. 
   
  
  
  
  21.             lock.readLock().lock();
    22. 
   
  
  
  
  22.             return super.get(key);
    23. 
   
  
  
  
  23.         } finally {
    24. 
   
  
  
  
  24.             lock.readLock().unlock();
    25. 
   
  
  
  
  25.         }
    26. 
   
  
  
  
  26.     }
    27. 
   
  
  
  
  27. 
   
  
  
  
  28.     @Override
    29. 
   
  
  
  
  29.     public V put(K key, V value) {
    30. 
   
  
  
  
  30.         try {
    31. 
   
  
  
  
  31.             lock.writeLock().lock();
    32. 
   
  
  
  
  32.             return super.put(key, value);
    33. 
   
  
  
  
  33.         } finally {
    34. 
   
  
  
  
  34.             lock.writeLock().unlock();
    35. 
   
  
  
  
  35.         }
    36. 
   
  
  
  
  36.     }
    37. 
   
  
  
  
  37.     //remove clear 略
    38. 
   
  
  
  
  38. }
    39.

内部是一个依赖LinkedHashMap实现的LRU缓存。看注释，目的是要构建一个限定容量、且不会进行扩容的MAP(百度了一波，和网上的实现一模一样~)。那么，实际情况真的和想象中的一样么?。

2.2 LinkedHashMap实现的LRUMap好使么

我们来看容量和扩容相关的设置：为什么设计者认为该LRUMap不会进行扩容?

  
 
 
 
    
   
  
  
  
  1. //**把容量和扩容相关的参数摘出来**
    2. 
   
  
  
  
  2. //用户期望的最大容量
    3. 
   
  
  
  
  3. private final int maxCapacity;
    4. 
   
  
  
  
  4. //加载系数
    5. 
   
  
  
  
  5. private static final float LOAD_FACTOR = 0.99f;
    6. 
   
  
  
  
  6. //构造函数中调用LinkedHashMap进行初始化
    7. 
   
  
  
  
  7. super(maxCapacity, LOAD_FACTOR, true);
    8. 
   
  
  
  
  8. 
   
  
  
  
  9. @Override  //复写删除最久元素条件方法
    10. 
   
  
  
  
  10. protected boolean removeEldestEntry(java.util.Map.Entry eldest) {
    11. 
   
  
  
  
  11.    //当LinkedHashMap.size 比 我们限定容量大时，执行删除
    12. 
   
  
  
  
  12.    return size() > maxCapacity;
    13. 
   
  
  
  
  13. }
    14.

按我们的实际使用实例化一下：

  • maxCapacity=6000，是我们希望的最大元素容量。
  • load_factor=0.99 加载因子。
  • Map内部threshold=8192*0.99=8110，是那么下次扩容时的容量大小。(map中table容量的真实大小是离6000最近的2的N次幂，即8192)。

因为复写了LRU条件函数，当size>6000时会进行LRU替换。因此，理论上，size永远不会达到8110。

怎么解决并发下的读写冲突呢?

  
 
 
 
    
   
  
  
  
  1. //读写锁
    2. 
   
  
  
  
  2. private final ReadWriteLock lock = new ReentrantReadWriteLock();
    3. 
   
  
  
  
  3.  
    4. 
   
  
  
  
  4. public V get(Object key) {
    5. 
   
  
  
  
  5.    try {
    6. 
   
  
  
  
  6.        lock.readLock().lock();
    7. 
   
  
  
  
  7.        return super.get(key);
    8. 
   
  
  
  
  8.    } finally {
    9. 
   
  
  
  
  9.        lock.readLock().unlock();
    10. 
   
  
  
  
  10.    }
    11. 
   
  
  
  
  11. }
    12. 
   
  
  
  
  12. 
   
  
  
  
  13. public V put(K key, V value) {
    14. 
   
  
  
  
  14.    try {
    15. 
   
  
  
  
  15.       lock.writeLock().lock();
    16. 
   
  
  
  
  16.       return super.put(key, value);
    17. 
   
  
  
  
  17.    } finally {
    18. 
   
  
  
  
  18.       lock.writeLock().unlock();
    19. 
   
  
  
  
  19.    }
    20. 
   
  
  
  
  20. }
    21.

设计者为了解决并发下的读写冲突，给查询和修改方法加了锁，为了兼顾性能，使用了读写锁：在get的时候加读锁，在put/remove的时候加写锁。

看起来，整个设计很好的解决了LRUMap的固定容量和并发操作问题，那么事实是什么样的呢?

其实，这个问题很早就有人分析过了[1] ，是因为LinkedHashMap在get读操作的时候，会为了维护LRU从而进行元素修改，即将get到的元素转移到链表最后。这样，就导致了读写并发问题，但这个解释感觉朦朦胧胧，因此，我决定在其基础上对读写并发问题再讲细致一些。

2.3 LinkedHashMap内存泄漏拆解

都加了读写锁为什么不好使呢?

这里我们还是需要先明确，读写锁的概念和适用场景：读写锁，允许多个线程共享读锁，适用于读多写少的情况。(前提是，读操作不会改变存储结构)

所以，问题就发生在get操作上，LinkedHashMap的get操作被重写，目的是为了实现LRU功能，在get之后，将当前节点移动到链表最后。

移动啊，同志们，这明显是一个写操作，所以，加读锁还有用么?

即允许多线程进入，又进行了修改，那还能起什么作用，能没有并发问题么?

下面，对照节点移动的代码，详细拆解一下多线程下的并发问题：

get之后的节点移动，将节点移动到最后

实际拆解分析如下，为什么在多线程的情况下，会出现内存泄漏：

时间片下多线程的get执行

我们看到，在线程1执行完前两句，让出了时间片，当线程2执行到p.after=null之后又出让了时间片，这样，本来a应该是后面的<2,B>节点，结果多线程下变成了null，最终，后面两个节点被踢出了链表，删除操作无法触达，造成内存泄漏。

验证的代码就不贴了，大家有兴趣可以自己试一下~

Part3 总结

话说回来，既然定位到了问题，这个内存泄漏怎么修复呢?

可以把读写锁改成互斥锁。或者直接用分布式存储，能慢多少呢，是不是，既方便，简单，又免得为了节约机器内存自己构造LRUMap。

每一个八股文都不只是为了面试，而是每次线上问题排查的基石。千万别把八股文的作用定位错了。。。

本文转载自微信公众号「Coder的技术之路  」，可以通过以下二维码关注。转载本文请联系Coder的技术之路公众号。

当前文章：高并发服务优化篇：详解一次由读写锁引起的内存泄漏
标题网址：http://www.mswzjz.cn/qtweb/news20/485620.html

攀枝花网站建设、攀枝花网站运维推广公司-贝锐智能，是专注品牌与效果的网络营销公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 贝锐智能

贝锐智能技术为您推荐以下文章

品牌网站制作知识

各行业网站

移动服务器托管　　 　成都响应式网站　　 　成都二枢电信服务器托管　　 　成都网络营销公司　　 　SSL证书　　 　成都小程序开发　　 　成都建站　　 　网站方案　　 　防护网厂　　 　子晨木包装箱　　 　装饰公司网站建设方案　　 　清舞人间　　 　新型地坪材料　　 　服务器租用　　 　手机网站设计　　 　成都柴油发电机租用　　 　成都微信小程序开发　　 　泸州洋跃建站　　 　乐山服务器托管　　 　成都康明斯发电机