JAVA并发编程

JAVA并发控制

一 为什么需要并发控制

之所以要控制并发是因为存在资源的竞争，假设不存在竞争的临界资源，并发控制也就不存在了。控制是为了能够控制各个线程合理正确的使用资源。并发的控制在各个编程语言都存在对应的实施方案。也有一些语言在这方面作的很好，比如：erlang以及新出的rust，它们在整个语言设计过程中将多线程并发考虑进去了，从而这也成了它们的特色。当今都是多核的时代，多线程并发将是水到渠成

当然多线程并发有很多解决方案。从硬件上面，可以通过分布式集群。从而将同一时间的服务并发压力分离到集群的每个实体中。还有从应用层面进行控制，比如对某个接口进行限流，通过控制某一时刻该接口所能承受的并发线程数量，这种模式可以通过Queue的模式来实现（这里只列举出此时本人所想到的，肯定存在其他解决方案）。那么今天只对JAVA在引用层面如何控制多线程并发场景的。

二 JAVA对并发提供了哪些API

1.synchronized

提到java的并发，第一个让我想到的就是synchronized关键词。这是接触J2SE介绍线程的时候一定会介绍的。只要载方法前面加上整个关键词修饰，那么整个方法就是线程安全的，即某一时刻只会有一个线程进入该方法。如下：

public void synchronized threadSafeMethod(){
......
}

当然可以进行块级的控制，如下：

public void threadSafeBlock(){
    synchronized(object){
        //thread safe 
    }
}

2.concurrent包

随着开发时间的推移知道了Doug lea这个人。知道了它的concurrent包，在该包中提供了基本满足JAVA在并发编程方面需要的API。比如原子操作类，线程安全的util类，异步执行的线程池，当然还有锁。

1）Lock

首先还是先上代码：

public class LockDemo {

private static final ReentrantLock lock = new ReentrantLock();


public void threadSafe(){
    try {
        lock.lockInterruptibly();
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    try{
        //do something
    }finally {
        lock.unlock();
    }
}

}

上面例子是ReentrantLock一个基础的例子，可以通过开启锁的范围来定义需要并发控制的范围，从而可以调节代码载性能上面的影响，如果范围越大，那么执行的性能受到的影响就越大。所以确定好锁的范围很重要。ReentrantLock可以通过newCndition方法创建一个条件，从而可以多线程中，可以通过Condition进行通信。下面给出了一个比较经典的例子：

public class LockDemo {

private static final ReentrantLock lock = new ReentrantLock();

private static final Condition notFull = lock.newCondition();

private static final Condition notEmpty = lock.newCondition();

private int maxSize=10;

private int currentSize=0;//存在多线程安全问题

private Object[] array = new Object[maxSize];


public void offer(Object item) throws InterruptedException {
    try {
        lock.lockInterruptibly();
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    try{
        if(maxSize==currentSize){
            notFull.await();//释放当前线程持有的锁，让给其他线程
        }
        array[currentSize]=item;
        currentSize++;
        notEmpty.signal();
    }finally {
        lock.unlock();
    }
}


public Object pop() throws InterruptedException {
    try {
        lock.lockInterruptibly();
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    try{
        if(currentSize==0){
            notEmpty.await();//释放当前线程持有的锁
        }
        currentSize--;
        Object item = array[currentSize];
        array[currentSize]=null;
        notFull.signal();
        return item;
    }finally {
        lock.unlock();
    }
}


}

上面代码实现了一个简单队列，offer和pop方法在进入方法第一步是申请一个锁，并且载最后都执行了解锁的操作。那么可以确保这两个方法在某一时刻肯定只能有一个线程执行，但是为了不超出队列的最大大小，offer和pop之间需要通信，当队列满了的时候，需要等待pop方法通知数组有空闲的位置，当队列空的时候，需要offer方法通知pop方法队列中已经有了数据，可以进行弹出。这个过程中Condition就起到了作用。载concurrent包中也提供了一套读写锁，实现了读写锁的机制，可以通过它来对同一个资源进行安全的多线程读写，下面也列举出了简单的例子：

public class LockDemo {

private static final ReadWriteLock readwriteLock = new ReentrantReadWriteLock();

public void read(){
    Lock lock = readwriteLock.readLock();
    try {
        lock.lockInterruptibly();
    } catch (InterruptedException e) {
        e.printStackTrace();
    }

    try{
        //do read
    }finally {
        lock.unlock();
    }
}

public void write(){
    Lock lock = readwriteLock.writeLock();
    try {
        lock.lockInterruptibly();
    } catch (InterruptedException e) {
        e.printStackTrace();
    }

    try{
        //do write
    }finally {
        lock.unlock();
    }

}


}

上面已经实现了一个简单的队列，并且载多线程下面是安全的，可以通过上面，可以实现一个线程安全的资源池，这个是基于锁的方式。那么可不可以不使用锁来实现一个池呢？那就需要用到信号量来进行控制了。代码如下：

 public class Pool {


private Semaphore semaphore ;

private LinkedList<Object> resources = new LinkedList<Object>();

public Pool(int size){
    semaphore = new Semaphore(size);//创建当前池可以容纳的多少资源
    initResource();
}

private void initResource() {
    //init resource
}


public void returnResource(Object item) throws InterruptedException {
    resources.offer(item);
    semaphore.release();//释放一个可用的信号
}


public Object pop() throws InterruptedException {
    semaphore.acquire();//请求当前时候有资源
    return resources.pop();
}
}

可以看到，每当一个线程来申请资源的时候，都需要通过Semaphore来申请，如果当前资源处于紧张不够，那么就会载 semaphore.acquire();进行阻塞，等待 semaphore.release();方法示范一个可用的资源。

2）atomic

我们知道Long类型在多线程操作下是不安全的，并且整形的“++/–”都不是线程安全的，因为看似只有一次操作，其实并不是，“++/–”其实就是“-1/+1”的操作，中间的操作并非原子性，至少需要取值，操作，赋值这三步，并且取值后，可能操作数被其他线程进行了修改，然后你拿到的是一个过期的数据，进行操作，然后再赋值给该变量，必然会导致数据的不正确性。那么你可能会说，我使用volatile修饰被操作的变量，但是volatile可以确保你读到的是最新的值，但是当多个线程都拿到最新的数据，并进行操作了，然后再写回内存的时候，同样也会导致并发情况的出现。

为了解决上面的问题，Doug lea载concurrent包下面设计了一套原子性的基础类型类。此时“++/–”在它里面是原子性的。解决该问题的方式，doug lea是使用了操作系统级别的cas（compare and set）的方式来做到的原子性的，它的底层是Unsafe类。如果有兴趣可以取了解一下，这里就不作过多的解释。

三 如何合理的使用并发控制API

整个话题貌似抛的有点大，我这里只阐述以下我的个人理解。从两天来进行分析。空间和时间。

1 空间

这个怎么说？如果看过ConcurrentHashMap源码的人都应该知道它是怎么优化的。我们知道HashTable是全局锁，所有的数据都用一把锁，这样的缺点是导致其他不存在竞争的资源也被锁作了。而Doug lea优化的方式是将数据进行拆分，分成段，每段共用一把锁，这样就避免了所有数据共用一把锁的尴尬局面，从而我对其中一段进行了锁住的时候，其他段还是可以操作的，这样提高了整个Map的执行效率。这里就是做了锁的空间优化，将一把锁控制的范围缩小，从而减少线程阻塞的时间，以提高效率。

2 时间

这里说的时间，是指当一个线程获取了锁之后，在执行被锁住区域代码的时候，减少其执行时间，从而减少其他线程阻塞的时间。上面说的actomic其实是拿时间来换取可靠并发的。因为采用的是CAS模式。大家看以下下面的代码就理解CAS是在做什么了：

public class SimpleAtomicInteger 
{
private volatile int value=0;

public int getAndIncrement(){
    while(true){
        int current = get();
        int next = current + 1;
        if (compareAndSet(current, next))
            return current;
    }
}

/**
 * 这里只是模拟系统底层的cas方法，假设这个方法是线程安全的
 * @param current
 * @param next
 * @return
 */
private boolean compareAndSet(int current, int next) {
    if(value==current){//假设当前的值没有变化，这进行赋值，否则返回false进行操作
        value=next;
        return true;
    }
    return false;
}

private int get() {
    return value;
}
}

通过上段代码应该知道为什么CAS会很消耗时间，当资源竞争激烈的时候，可能一个线程一直阻塞载while循环里面，每当然，这是比较极端的情况。所以如果能够尽量减少cas,那么势必将会提高整个代码的效率（这里有一篇关于Doug lea对AtomicInteger的优化，从而提高它的效率http://ifeve.com/better_atomicinteger/，方案就是减少CAS）？那么如果我们能够减少锁住代码的执行时间，时候也会提高整个代码的并发执行效率。