《Java高并发程序设计》学习 --4.1 有助于提高“锁”性能的几点建议

45 篇文章 0 订阅
1)减小锁持有时间
对于使用锁进行并发控制的应用程序而言,在锁竞争过程中,单个线程对锁的持有时间与系统性能有着直接关系。如果线程持有锁的时间很长,相对地,锁的竞争程度也就越激烈。程序开发过程中,应该尽可能地减少对某个锁的占有时间,以减少线程间互斥的可能。以下面代码为例:
public synchronized void syncMethod() {
    othercode1();
    mutexMethod();
    othercode2();
} 
syncMethod()方法中,假设只有mutexMethod()方法是有同步的需要的,而othercode1()和othercode2()并不需要做同步控制。如果othercode1()和othercode2()分别是重量级的方法,则会花费较长的CPU时间。此时,如果在并发量较大,使用这种对整个方法做同步的方案,会导致等待线程大量增加。因为一个线程,在进入该方法时获得内部锁,只有在所有任务都执行完后,才会释放锁。
一个较为优化的解决方案是,只在必要时进行同步,这样就能明显减少线程持有锁的时间,提高系统吞吐量。
public void syncMethod() {
    othercode1();
    synchronized(this) {
        mutexMethod();
    }
    othercode2();
}
在改进的代码中,只针对mutexMethod()方法做起了同步,锁占用的时间相对较短,因此能有更高的并行度。这种技术手段在JDK的源码包中也可以很容易地找到,比如处理正则表达式的pattern类:
public Matcher matcher(CharSequence input) {
    if (!compiled) {
        synchronized(this) {
            if (!compiled)
                compile();
        }
    }
    Matcher m = new Matcher(this, input);
    return m;
}
matcher()方法有条件地进行锁申请,只有在表达式未编译时,进行局部的加锁。这种处理方式大大提高了matcher()方法的执行效率和可靠性。
2)减小锁粒度
减小锁粒度也是一种削弱多线程锁竞争的有效手段。这种技术典型的使用场景就是ConcurrentHashMap类的实现。
对于HashMap来说,最重要的两个方法就是get()和put()。一种最自然的的想法就是对整个HashMap加锁,必然可以得到一个线程安全的对象。但是这样做,我们就认为加锁粒度太大。对于ConcurrentHashMap,它内部进一步细分了若干个小的HashMap,称之为段(SEGMENT)。默认情况下,一个ConcurrentHashMap被进一步细分为16个段。
如果需要在ConcurrentHashMap中增加一个新的表项,并不是将整个HashMap加锁,而是首先根据hashcode得到该表项应该被存放到哪个段中,然后对该段加锁,并完成put()操作。在多线程环境中,如果多个线程同时进行put()操作,只要被加入的表项不存放在同一个段中,则线程间便可以做到真正的并行。
下面的代码显示了put()操作的过程。在第5~6行,根据key,获得对应的段的序号。接着在第9行,得到段,然后将数据插入给定的段中。
public V put(K key, V value) {
    Segment<K,V> s;
    if (value == null)
        throw new NullPointerException();
    int hash = hash(key);
    int j = (hash >>> segmentShift) & segmentMask;
    if ((s = (Segment<K,V>)UNSAFE.getObject // nonvolatile; recheck
      (segments, (j << SSHIFT) + SBASE)) == null) // in ensureSegment
        s = ensureSegment(j);
    return s.put(key, hash, value, false);
}
减少锁粒度会引入一个新的问题,即:当系统需要取得全局锁时,其消耗的资源会比较多。仍然以ConcurrentHashMap类为例,虽然其put()方法很好地分离了锁,但是当试图访问ConcurrentHashMap全局信息时,就会需要同时取得所有段的锁方能顺利实施。比如ConcurrentHashMap的size()方法,它将返回ConcurrentHashMap的有效表项的数量,即ConcurrentHashMap的全部有效表项之和。要获得这个信息需要取得所有子段的锁,因此,其size()方法的部分代码如下:
sum = 0;
for(int i=0; i<segments.length; ++i)
    segments[i].lock();
for(int i=0; i<segments.length; ++i)
    sum += segments[i].count;
for(int i=0; i<segments.length; ++i)
    segments[i].unlock();
可以看到在计算总数时,先要获得所有段的锁,然后再求和。但是,ConcurrentHashMap的size()方法并不总是这样执行,事实上,size()方法会先使用无锁的方式求和,如果失败才会尝试这种加锁的方法。
3)读写分离锁来替换独占锁
在读多写少的场合,读写锁对系统性能是很有好处的。因为如果系统在读写数据时均使用独占锁,那么读操作和写操作间、读操作和读操作间、写操作和写操作间均不能做到真正的并发,并且需要相互等待。而读操作本身不会影响数据的完整性和一致性。因此,理论上,在大部分情况下,应该可以允许多线程同时读,读写锁正是实现了这种功能。
4)锁分离
将读写锁的思想做进一步的延伸,就是锁分离。读写锁根据读写操作功能上的不同,进行了有效的锁分离。依据应用程序的功能特点,使用类似的分离思想,也可以对独占锁进行分离。一个典型的案例就是java.util.concurrent.LinkedBlockingQueue的实现。
在LinkedBlockingQueue的实现中,take()函数和put()函数分别实现了从队列中取得数据和往队列中增加数据的功能。虽然两个函数都对当前队列进行了修改操作,但由于LinkedBlockingQueue是基于链表的,因此,两个操作分别作用于队列的前端和尾端,从理论上说,并不冲突。
如果使用独占锁,则要求在两个操作进行时获取当前队列的独占锁,那么take()和put()操作就不可能真正的并发,在运行时,它们会彼此等待对方释放锁资源。在这种情况下,锁竞争会相对比较激烈,从而影响程序在高并发时的性能。
因此,在JDK的实现中,并没有采用这样的方式,取而代之的是两把不同的锁,分离了take()和put()操作。
/** Lock held by take, poll, etc */
private final ReentrantLock takeLock = new ReentrantLock();

/** Wait queue for waiting takes */
private final Condition notEmpty = takeLock.newCondition();

/** Lock held by put, offer, etc */
private final ReentrantLock putLock = new ReentrantLock();

/** Wait queue for waiting puts */
private final Condition notFull = putLock.newCondition();
以上代码片段,定义了takeLock和putLock,它们分别在take()操作和put()操作中使用。因此,take()函数和put()函数就此相互独立,它们之间不存在锁竞争关系,只需要在take()和take()间、put()和put()间分别对takeLock和putLock进行竞争。从而,削弱了锁竞争的可能性。
函数take()的实现如下:
public E take() throws InterruptedException {
    E x;
    int c = -1;
    final AtomicInteger count = this.count;
    final ReentrantLock takeLock = this.takeLock;
    takeLock.lockInterruptibly(); //不能有两个线程同时取数据
    try {
        while (count.get() == 0) { //如果当前没有可用数据,一直等待
            notEmpty.await(); //等待,put()操作的通知
        }
        x = dequeue(); //取得第一个数据
        c = count.getAndDecrement(); //数量减1,原子操作
        if (c > 1)
            notEmpty.signal(); //通知其他take()操作
        } finally {
            takeLock.unlock(); //释放锁
        }
    if (c == capacity)
        signalNotFull(); //通知put()操作,已有空余空间
    return x;
}
函数put()的实现如下,
public void put(E e) throws InterruptedException {
    if (e == null) throw new NullPointerException();
    int c = -1;
    Node<E> node = new Node(e);
    final ReentrantLock putLock = this.putLock;
    final AtomicInteger count = this.count;
    putLock.lockInterruptibly(); //不能有两个线程同时进行put()
    try {
        while (count.get() == capacity) { //如果队列已经满了
            notFull.await(); //等待
        }
        enqueue(node); //插入数据
        c = count.getAndIncrement(); //更新总数,变量c是count加1前的值
        if (c + 1 < capacity)
            notFull.signal(); //有足够的空间,通知其他线程
    } finally {
        putLock.unlock(); //释放锁
    }
    if (c == 0)
    signalNotEmpty(); //插入成功后,通知take()操作取数据
}
通过takeLock和putLock两把锁,LinkedBlockingQueue实现了取数据和写数据的分离,使两者在真正意义上成为可并发的操作。
5)锁粗化
通常情况下,为了保证多线程间的有效并发,会要求每个线程持有锁的时间尽量短,即在使用完公共资源后,应该立即释放锁。只有这样,等待在这个锁上的其他线程才能尽早地获得资源执行任务。但是,如果对同一个锁不停地进行请求、同步和释放,其本身也会消耗系统宝贵的资源,反而不利于性能的优化。
为此,虚拟机在遇到一连串连读地对同一锁不断进行请求和释放的操作时,便会把所有的锁作整合成对锁的一次请求,从而减少对锁的请求同步次数,这个操作叫做锁是粗化。比如代码段:
public void demoMethod() {
    synchronized(lock) {
        //do sth
    }
    //做其他不需要的同步的工作,但能很快执行完毕
    synchronized(lock) {
        //do sth
    }
}
会被整合成如下形式:
public void demoMethod() {
    synchronized(lock) {
        //do sth
        //做其他不需要的同步的工作,但能很快执行完毕
    }
}
在开发过程中,也应该有意识地在合理的场合进行锁的粗化,尤其当在循环内请求锁时。以下是一个循环内请求锁的例子,在这种情况下,意味着每次循环都有申请锁和释放锁的操作。但在这种情况下,显然是没有必要的。
for(int i=0; i<CIECLE; i++) {
    synchronized(lock) {
    }
}
所以,一种更加合理的做法应该是在外层只请求一次锁:
synchronized(lock) {
    for(int i=0; i<CIECLE; i++) {
    }
}



注:本篇博客内容摘自《Java高并发程序设计》

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值