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

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

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

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

Part1线上服务器报警了

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

1.1先看表现

老年代内存占用

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

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

内存泄漏了~

1.2怎么办呢

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

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

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

Part2定位问题

一般的步骤:

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

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

2.1定位问题代码

jmap结果查看

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

private static final CacheMap<String, List<GeoDispLocal>> NEAR_DISTRICT_CACHE = new CacheMap<String, List<GeoDispLocal>>(3600 * 1000, 1000);
private static final CacheMap<Integer, Point> LOCAL_POINT_CACHE = new CacheMap<Integer, Point>(3600 * 1000, 6000);

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

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

public class CacheMap<K, V> {
    private final long expireMs;
    private LRUMap<K, CacheMap.Entry<V>> valueMap;
    //其他略
}

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

public class LRUMap<K, V> extends LinkedHashMap<K, V> {
    private static final long serialVersionUID = 1L;
    private final int maxCapacity;
    // 这个map不会扩容
    private static final float LOAD_FACTOR = 0.99f;
    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    public LRUMap(int maxCapacity) {
        super(maxCapacity, LOAD_FACTOR, true);
        this.maxCapacity = maxCapacity;
    }
    @Override
    protected boolean removeEldestEntry(java.util.Map.Entry<K, V> eldest) {
        return size() > maxCapacity;
    }
    @Override
    public V get(Object key) {
        try {
            lock.readLock().lock();
            return super.get(key);
        } finally {
            lock.readLock().unlock();
        }
    }
    @Override
    public V put(K key, V value) {
        try {
            lock.writeLock().lock();
            return super.put(key, value);
        } finally {
            lock.writeLock().unlock();
        }
    }
    //remove clear 略
}

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

2.2LinkedHashMap实现的LRUMap好使么

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

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

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

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

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

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

//读写锁
private final ReadWriteLock lock = new ReentrantReadWriteLock();
public V get(Object key) {
   try {
       lock.readLock().lock();
       return super.get(key);
   } finally {
       lock.readLock().unlock();
   }
}
public V put(K key, V value) {
   try {
      lock.writeLock().lock();
      return super.put(key, value);
   } finally {
      lock.writeLock().unlock();
   }
}

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

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

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

2.3LinkedHashMap内存泄漏拆解

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

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

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

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

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

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

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

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

时间片下多线程的get执行

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

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

Part3总结

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

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

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

本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。

相关文章
|
1月前
|
存储 缓存 监控
|
1月前
|
存储 安全 Java
jvm 锁的 膨胀过程?锁内存怎么变化的
【10月更文挑战第3天】在Java虚拟机(JVM)中,`synchronized`关键字用于实现同步,确保多个线程在访问共享资源时的一致性和线程安全。JVM对`synchronized`进行了优化,以适应不同的竞争场景,这种优化主要体现在锁的膨胀过程,即从偏向锁到轻量级锁,再到重量级锁的转变。下面我们将详细介绍这一过程以及锁在内存中的变化。
37 4
|
1月前
|
缓存 算法 Java
Java中的内存管理:理解与优化
【10月更文挑战第6天】 在Java编程中,内存管理是一个至关重要的主题。本文将深入探讨Java内存模型及其垃圾回收机制,并分享一些优化内存使用的策略和最佳实践。通过掌握这些知识,您可以提高Java应用的性能和稳定性。
48 4
|
1月前
|
存储 监控 固态存储
在高并发环境下,如何优化 WAL 的写入性能?
在高并发环境下,如何优化 WAL 的写入性能?
|
12天前
|
缓存 算法 Java
本文聚焦于Java内存管理与调优,介绍Java内存模型、内存泄漏检测与预防、高效字符串拼接、数据结构优化及垃圾回收机制
在现代软件开发中,性能优化至关重要。本文聚焦于Java内存管理与调优,介绍Java内存模型、内存泄漏检测与预防、高效字符串拼接、数据结构优化及垃圾回收机制。通过调整垃圾回收器参数、优化堆大小与布局、使用对象池和缓存技术,开发者可显著提升应用性能和稳定性。
35 6
|
12天前
|
监控 安全 程序员
如何使用内存池池来优化应用程序性能
如何使用内存池池来优化应用程序性能
|
12天前
|
存储 监控 Java
深入理解计算机内存管理:优化策略与实践
深入理解计算机内存管理:优化策略与实践
|
24天前
|
监控 Java 数据库连接
线程池在高并发下如何防止内存泄漏?
线程池在高并发下如何防止内存泄漏?
|
24天前
|
存储 JavaScript 前端开发
如何优化代码以避免闭包引起的内存泄露
本文介绍了闭包引起内存泄露的原因,并提供了几种优化代码的策略,帮助开发者有效避免内存泄露问题,提升应用性能。
|
25天前
|
并行计算 算法 IDE
【灵码助力Cuda算法分析】分析共享内存的矩阵乘法优化
本文介绍了如何利用通义灵码在Visual Studio 2022中对基于CUDA的共享内存矩阵乘法优化代码进行深入分析。文章从整体程序结构入手,逐步深入到线程调度、矩阵分块、循环展开等关键细节,最后通过带入具体值的方式进一步解析复杂循环逻辑,展示了通义灵码在辅助理解和优化CUDA编程中的强大功能。