最近在工作上碰见了一些高并发的场景需要加锁来保证业务逻辑的正确性,并且要求加锁后性能不能受到太大的影响。初步的想法是通过数据的时间戳,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自带锁的封装,浪费了不少时间。
实际上在实现了这些细粒度锁之后,又有了新的想法,比如可以通过分段思想将数据提交给专门的线程来处理,可以减少大量线程的阻塞时间,留待日后探索...
本文向大家介绍java基于ConcurrentHashMap设计细粒度实现代码,包括了java基于ConcurrentHashMap设计细粒度实现代码的使用技巧和注意事项,需要的朋友参考一下 细粒度锁: java中的几种锁:synchronized,ReentrantLock,ReentrantReadWriteLock已基本可以满足编程需求,但其粒度都太大,同一时刻只有一个线程能进
本文向大家介绍Android亮度调节的几种实现方法,包括了Android亮度调节的几种实现方法的使用技巧和注意事项,需要的朋友参考一下 最近在做一个App的设置项,亮度调节。真正做时,发现Android亮度调节比预想要复杂一些。其实目前网上已有不少这方面的资料,但有些博文具有一定误导性。在此将这块内容按照自己理解整理一下。 整体上看,Android亮度调节分为三个层次,分别是:Android系统亮
本文向大家介绍Java单例模式实现的几种方式,包括了Java单例模式实现的几种方式的使用技巧和注意事项,需要的朋友参考一下 Java单例模式实现的几种方式 单例模式好多书上都是这么写的: 但是实际开发中是不会这么写的,因为有一个严重的问题,多线程并发访问的时候,可能会产生多个实例!! 下面列举几个常用的方法: 1.使用synchronized 关键字 2.加锁 3.利用静态变量: 以上就
语言是一种规范,要想使用它,需要将其实体化,用编译原理的话讲,可以大致分为编译器和解释器,而根据之前说的,如果把目标代码的解释过程看做解析过程,比如x86机器指令load到cpu时,根据不同的指令进行不同的运算,以及字节码的分派等,这个界限是模糊的 因此,这个事情可以这么讲,假设我们已经有一台机器M,它可以接收A语言并完成计算工作,则对于高级语言B来说,我们只要将其转换成A语言即可。根据实际情况,
本文向大家介绍Java 多线程有几种实现方式?相关面试题,主要包含被问及Java 多线程有几种实现方式?时的应答技巧和注意事项,需要的朋友参考一下 有4种,分别是: 继承Thread类 实现Runnable接口 实现Callable接口通过FutureTask包装器来创建Thread线程 通过线程池创建线程,使用线程池接口ExecutorService结合Callable、Future实现有返回结
问题内容: 通过将GET中的版本号传回PUT调用,我对与数据库表进行一对一映射的REST资源实现了乐观锁定。如果在执行GET和PUT的时间之间数据库中的版本号发生了更改,则发生了乐观锁异常。相当简单的设计。 现在,如何对映射到多个数据库表的复合REST资源执行相同的操作?我不想回传多个版本字段(与复合资源相关的每个数据表一个)。复合资源的一个简单示例是/ FooBar,其中/ Foo和/ Bar是