JAVA细粒度锁实现的几种方式

原创
2016/05/10 18:49
阅读数 2.3W

    最近在工作上碰见了一些高并发的场景需要加锁来保证业务逻辑的正确性,并且要求加锁后性能不能受到太大的影响。初步的想法是通过数据的时间戳,id等关键字来加锁,从而保证不同类型数据处理的并发性。而java自身api提供的锁粒度太大,很难同时满足这些需求,于是自己动手写了几个简单的扩展...

    1. 分段锁

        借鉴concurrentHashMap的分段思想,先生成一定数量的锁,具体使用的时候再根据key来返回对应的lock。这是几个实现里最简单,性能最高,也是最终被采用的锁策略,代码如下:

/**
 * 分段锁,系统提供一定数量的原始锁,根据传入对象的哈希值获取对应的锁并加锁
 * 注意:要锁的对象的哈希值如果发生改变,有可能导致锁无法成功释放!!!
 */
public class SegmentLock<T> {
    private Integer segments = 16;//默认分段数量
    private final HashMap<Integer, ReentrantLock> lockMap = new HashMap<>();

    public SegmentLock() {
        init(null, false);
    }

    public SegmentLock(Integer counts, boolean fair) {
        init(counts, fair);
    }

    private void init(Integer counts, boolean fair) {
        if (counts != null) {
            segments = counts;
        }
        for (int i = 0; i < segments; i++) {
            lockMap.put(i, new ReentrantLock(fair));
        }
    }

    public void lock(T key) {
        ReentrantLock lock = lockMap.get((key.hashCode()>>>1) % segments);
        lock.lock();
    }

    public void unlock(T key) {
        ReentrantLock lock = lockMap.get((key.hashCode()>>>1) % segments);
        lock.unlock();
    }
}

    2. 哈希锁

        上述分段锁的基础上发展起来的第二种锁策略,目的是实现真正意义上的细粒度锁。每个哈希值不同的对象都能获得自己独立的锁。在测试中,在被锁住的代码执行速度飞快的情况下,效率比分段锁慢 30% 左右。如果有长耗时操作,感觉表现应该会更好。代码如下:

public class HashLock<T> {
    private boolean isFair = false;
    private final SegmentLock<T> segmentLock = new SegmentLock<>();//分段锁
    private final ConcurrentHashMap<T, LockInfo> lockMap = new ConcurrentHashMap<>();

    public HashLock() {
    }

    public HashLock(boolean fair) {
        isFair = fair;
    }

    public void lock(T key) {
        LockInfo lockInfo;
        segmentLock.lock(key);
        try {
            lockInfo = lockMap.get(key);
            if (lockInfo == null) {
                lockInfo = new LockInfo(isFair);
                lockMap.put(key, lockInfo);
            } else {
                lockInfo.count.incrementAndGet();
            }
        } finally {
            segmentLock.unlock(key);
        }
        lockInfo.lock.lock();
    }

    public void unlock(T key) {
        LockInfo lockInfo = lockMap.get(key);
        if (lockInfo.count.get() == 1) {
            segmentLock.lock(key);
            try {
                if (lockInfo.count.get() == 1) {
                    lockMap.remove(key);
                }
            } finally {
                segmentLock.unlock(key);
            }
        }
        lockInfo.count.decrementAndGet();
        lockInfo.unlock();
    }

    private static class LockInfo {
        public ReentrantLock lock;
        public AtomicInteger count = new AtomicInteger(1);

        private LockInfo(boolean fair) {
            this.lock = new ReentrantLock(fair);
        }

        public void lock() {
            this.lock.lock();
        }

        public void unlock() {
            this.lock.unlock();
        }
    }
}

 

    3. 弱引用锁

        哈希锁因为引入的分段锁来保证锁创建和销毁的同步,总感觉有点瑕疵,所以写了第三个锁来寻求更好的性能和更细粒度的锁。这个锁的思想是借助java的弱引用来创建锁,把锁的销毁交给jvm的垃圾回收,来避免额外的消耗。

        有点遗憾的是因为使用了ConcurrentHashMap作为锁的容器,所以没能真正意义上的摆脱分段锁。这个锁的性能比 HashLock 快10% 左右。锁代码:

/**
 * 弱引用锁,为每个独立的哈希值提供独立的锁功能
 */
public class WeakHashLock<T> {
    private ConcurrentHashMap<T, WeakLockRef<T, ReentrantLock>> lockMap = new ConcurrentHashMap<>();
    private ReferenceQueue<ReentrantLock> queue = new ReferenceQueue<>();

    public ReentrantLock get(T key) {
        if (lockMap.size() > 1000) {
            clearEmptyRef();
        }
        WeakReference<ReentrantLock> lockRef = lockMap.get(key);
        ReentrantLock lock = (lockRef == null ? null : lockRef.get());
        while (lock == null) {
            lockMap.putIfAbsent(key, new WeakLockRef<>(new ReentrantLock(), queue, key));
            lockRef = lockMap.get(key);
            lock = (lockRef == null ? null : lockRef.get());
            if (lock != null) {
                return lock;
            }
            clearEmptyRef();
        }
        return lock;
    }

    @SuppressWarnings("unchecked")
    private void clearEmptyRef() {
        Reference<? extends ReentrantLock> ref;
        while ((ref = queue.poll()) != null) {
            WeakLockRef<T, ? extends ReentrantLock> weakLockRef = (WeakLockRef<T, ? extends ReentrantLock>) ref;
            lockMap.remove(weakLockRef.key);
        }
    }

    private static final class WeakLockRef<T, K> extends WeakReference<K> {
        final T key;

        private WeakLockRef(K referent, ReferenceQueue<? super K> q, T key) {
            super(referent, q);
            this.key = key;
        }
    }
}

 

后记

    最开始想借助 locksupport 和 AQS 来实现细粒度锁,写着写着发现正在实现的东西和java 原生的锁区别不大,于是放弃改为对java自带锁的封装,浪费了不少时间。

    实际上在实现了这些细粒度锁之后,又有了新的想法,比如可以通过分段思想将数据提交给专门的线程来处理,可以减少大量线程的阻塞时间,留待日后探索...

 

展开阅读全文
打赏
22
313 收藏
分享
加载中
while (lock == null) {
lockMap.putIfAbsent(key, new WeakLockRef<>(new ReentrantLock(), queue, key));
lockRef = lockMap.get(key);
//极端情况下下边一行中第二个lockRef可能空指针,因为判空与使用它不是原子的,判空后get前,另一个线程可能调用clearEmptyRef方法移除掉。
lock = (lockRef == null ? null : lockRef.get());
if (lock != null) {
return lock;
}
clearEmptyRef();
}
03/28 08:15
回复
举报
想错,没有问题。lockRef已经是一个强引用直接指向weakLockRef对象了。。lockRef不可能被回收,可能空的是lockRef.get(),而下一步作了进一步判断。网站怎么不能删除错误回复了😰
03/28 08:26
回复
举报
那个 哈希锁 实现的不好! 如果你用double-check的方式,理论上不会那么慢!
2018/04/17 10:33
回复
举报
取hashcode之后为什么要右移一位?
2017/05/01 10:46
回复
举报
GameKing博主

引用来自“这个男人来自地球”的评论

额。居然不能编辑评论。上面回复有错。。醉了。。可能理解错楼主的意思了。
“lock有值。thread2也获取到lock。”这后面还有句话:可能楼主就是想这样设计的,就让thread2执行lock()阻塞吧。我理解成错了。
嗯,第三个其实是一个锁生成器,处理锁的生成回收逻辑,加锁与释放是lock本身的特性。
2017/01/22 18:51
回复
举报
额。居然不能编辑评论。上面回复有错。。醉了。。可能理解错楼主的意思了。
“lock有值。thread2也获取到lock。”这后面还有句话:可能楼主就是想这样设计的,就让thread2执行lock()阻塞吧。我理解成错了。
2017/01/22 17:39
回复
举报

引用来自“这个男人来自地球”的评论

楼主还在?
请问:这里lockInfo.count.get() == 1 为什么写2次?第1个key被lock,lockInfo.count已经不可能被修改了吧。
if (lockInfo.count.get() == 1) {
      segmentLock.lock(key);
      try {
        if (lockInfo.count.get() == 1) {
          lockMap.remove(key);
        }
      } finally {
        segmentLock.unlock(key);
      }
    }

引用来自“GameKing”的评论

从第一次判断到加锁这段时间内,其它线程有获取锁的可能,所以在加锁保证独占后,还要再判断一次...

引用来自“这个男人来自地球”的评论

segmentLock.lock(key);这不是调用ReentrantLock的lock?其他线程执行到这,也被阻塞了。还需要保证持有锁的独占性?

引用来自“GameKing”的评论

假设程序跑的龟速,从第一次判断 lockInfo.count.get() == 1 通过到 segmentLock.lock(key) 成功加锁之间花了一小时,会怎么样呢?是不是有可能存在一个哈希值相同的对象趁着这段时间调用了一下 HashLock 的 lock 方法? 推演一下流程。
👍 这...我没有想到。是有这种可能。。
2017/01/22 17:35
回复
举报

引用来自“这个男人来自地球”的评论

楼主还在?
请问:这里lockInfo.count.get() == 1 为什么写2次?第1个key被lock,lockInfo.count已经不可能被修改了吧。
if (lockInfo.count.get() == 1) {
      segmentLock.lock(key);
      try {
        if (lockInfo.count.get() == 1) {
          lockMap.remove(key);
        }
      } finally {
        segmentLock.unlock(key);
      }
    }

引用来自“GameKing”的评论

从第一次判断到加锁这段时间内,其它线程有获取锁的可能,所以在加锁保证独占后,还要再判断一次...
第3个锁。不好意思。我没有测试过。只是看代码,有点疑问。我把疑问描述清楚下。
1:thread1执行get(key)获取到锁,thread1执行200s。
在thread1执行第10s时,thread2执行get(key),执行到
WeakReference lockRef = lockMap.get(key);
ReentrantLock lock = (lockRef == null ? null : lockRef.get());
lock有值。thread2也获取到lock。

2:thread1执行完结束。正常流程应该是unlock锁了。可是第3个锁把unlock丢给JVM的gc。如果thread1执行完,在gc前,thread2获取锁。这种情况锁的意义就变了。不符合互斥量的概念。同时thread2会被阻塞。gc也不会销毁。
2017/01/22 17:33
回复
举报
GameKing博主

引用来自“这个男人来自地球”的评论

楼主还在?
请问:这里lockInfo.count.get() == 1 为什么写2次?第1个key被lock,lockInfo.count已经不可能被修改了吧。
if (lockInfo.count.get() == 1) {
      segmentLock.lock(key);
      try {
        if (lockInfo.count.get() == 1) {
          lockMap.remove(key);
        }
      } finally {
        segmentLock.unlock(key);
      }
    }

引用来自“GameKing”的评论

从第一次判断到加锁这段时间内,其它线程有获取锁的可能,所以在加锁保证独占后,还要再判断一次...

引用来自“这个男人来自地球”的评论

segmentLock.lock(key);这不是调用ReentrantLock的lock?其他线程执行到这,也被阻塞了。还需要保证持有锁的独占性?
假设程序跑的龟速,从第一次判断 lockInfo.count.get() == 1 通过到 segmentLock.lock(key) 成功加锁之间花了一小时,会怎么样呢?是不是有可能存在一个哈希值相同的对象趁着这段时间调用了一下 HashLock 的 lock 方法? 推演一下流程。
2017/01/22 17:21
回复
举报

引用来自“这个男人来自地球”的评论

楼主还在?
请问:这里lockInfo.count.get() == 1 为什么写2次?第1个key被lock,lockInfo.count已经不可能被修改了吧。
if (lockInfo.count.get() == 1) {
      segmentLock.lock(key);
      try {
        if (lockInfo.count.get() == 1) {
          lockMap.remove(key);
        }
      } finally {
        segmentLock.unlock(key);
      }
    }

引用来自“GameKing”的评论

从第一次判断到加锁这段时间内,其它线程有获取锁的可能,所以在加锁保证独占后,还要再判断一次...
segmentLock.lock(key);这不是调用ReentrantLock的lock?其他线程执行到这,也被阻塞了。还需要保证持有锁的独占性?
2017/01/22 17:09
回复
举报
GameKing博主

引用来自“_鱼_”的评论

思路很棒。第一段代码分段锁那里,(key.hashCode()>>>1) % segments改成key.hashCode()& (segments-1)速度会快不少。
👍
2017/01/22 15:57
回复
举报
更多评论
打赏
38 评论
313 收藏
22
分享
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部