Java 多线程-线程同步(一)

  Java中的多线程同步是一个非常大的问题，由于能力有限，所以只会介绍一些简单的知识点。由于这个方向的知识很多，所以文章会分为多个部分。

1.同步例子

  由于要讲到同步，例子肯定不能缺。同时这个例子，也用于后面的同步机制。

Bank类：

public class Bank {
    private int count = 1000;
    
    public void reduce() {
        if(count >= 100) {
            count -= 100;
            System.out.println("count = " + count);
        }
    }
    
    public int getCount() {
        return count;
    }
}

MyRunnable类：

public class MyRunnable implements Runnable{

    private Bank bank  = null;
    public MyRunnable(Bank bank) {
        this.bank = bank;
    }
    
    @Override
    public void run() {
        while(true) {
            bank.reduce();
            if(bank.getCount() <= 0) {
                break;
            }
        }
    }

}

Demol类：

public class Demo {
    public static void main(String[] args) {
        Thread threads[] = new Thread[4];
        Bank bank = new Bank();
        for(int i = 0; i < threads.length; i++) {
            threads[i] = new Thread(new MyRunnable(bank));
        }
        for(int i = 0; i < threads.length; i++) {
            threads[i].start();
        }
    }
}

  看一下这个例子，非常的简单，我们开启了4个线程，同时对Bank类里面的count属性进行减100的操作，如果count <= 0，那么线程就退出循环，进行对Bank类的count属性减100的操作。
  然后我们来看看结果：

  是不是感觉没什么问题？其实不对的，按照我们定义的规则来说，count应该是从1000一次变为0，是这样的：

  这种现象导致的原因也是非常的简单：Bank类的reduce方法不是同步，可以被多个线程执行，所以导致了在同一个时刻不同的线程获得count的值可能是不同的。

2. 锁对象

  上面看到了一个简单的多线程导致安全性的问题，从而得知，线程安全是多么的重要。在这里，将展示一个方式来保证线程同步。
  从JDK 1.5开始，Java引入了一个类--ReentrantLock类。这个类与操作系统里面的锁非常的相似。现在我们来看一下它的简单应用。
我们改写Bank的代码：

public class Bank {
    private int count = 1000;
    private ReentrantLock lock = new ReentrantLock();

    public void reduce() {
        //加锁
        lock.lock();
        if (count >= 100) {
            count -= 100;
            System.out.println("count = " + count);
        }
        //释放锁
        lock.unlock();
    }
    public int getCount() {
        return count;
    }
}

  你们会发现，我们在reduce方法里面通过ReetrantLock的lock方法进行加锁，当执行完毕之后，然后获得锁进行释放，使得其他线程能够有机会获得锁。这里需要说明的是，当那么没有获得锁的线程执行到lock.lock()方法那里的时候，会自动阻塞，直到获得锁的线程释放锁。注意分清阻塞和等待的区别。
  此时我们再来看看程序运行的效果：

注意：最好是把解锁的操作放在finally里面，因为一旦在加锁和释放锁之间发生了异常，解锁不能进行执行，导致程序进入死锁的状态。

3. 条件对象

 &esmp;通常来说，会遇到这种情况，就是当前这个线程获得了锁，但是进入临界区后，发现不能进行任何的操作，相当于是当前线程获得锁是多余的。例如，在reduce方法中，之前我们是这样加锁：

    public void reduce() {
        //加锁
        lock.lock();
        if (count >= 100) {
            count -= 100;
            System.out.println("count = " + count);
        }
        //释放锁
        lock.unlock();
    }

  像这种加锁方式，有一个问题，就是当一个线程获得了一个锁对象时，发现当前的count < 100,根本就不能减，于是只能失魂落魄的退出临界区，不能对count进行任何的操作(我们此时假设有几个线程在对count进行加100的操作，有几个线程对count进行减100的操作)。
例如：

public class Bank {
    private int count = 1000;
    private ReentrantLock lock = new ReentrantLock();

    public void reduce() {
        //加锁
        lock.lock();
        if (count >= 100) {
            count -= 100;
            System.out.println("count = " + count);
        }
        //释放锁
        lock.unlock();
    }

    public void add() {
        lock.lock();
        if (count < 1000) {
            count += 10;
            System.out.println("count = " + count);
        }
        
        lock.unlock();
    }

    public int getCount() {
        return count;
    }
}

  此时我们在Bank类中加了一个add方法，用来对count的属性进行加100的操作。当一个线程调用reduce方法获得了一个锁对象时，发现count已经小于了100，因此不能对count进行任何，只有默默的退出。像这种情况，多么的不好，对这个线程多么的不公平，人家辛辛苦苦获得锁对象就这样浪费了。
  我们这样来想，假设当前的线程获得了锁对象，发现不能对count进行任何的操作，然后阻塞自己，并且释放锁，等待调用add方法的线程进行。
  想法不错，其实条件对象就是这样执行的。

public class Bank {
    private int count = 1000;
    private ReentrantLock lock = null;
    private Condition condition = null;

    public Bank() {
        lock = new ReentrantLock();
        condition = lock.newCondition();
    }

    public void reduce() {
        lock.lock();
        try {
            if (count < 100) {
                condition.await();
            } else {
                count -= 100;
                System.out.println("count = " + count);
            }
            condition.signalAll();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }

    public void add() {
        lock.lock();
        try {
            if (count >= 1000) {
                condition.await();
            } else {
                count += 100;
                System.out.println("count = " + count);
            }
            condition.signalAll();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }finally {
            lock.unlock();
        }
    }

    public int getCount() {
        return count;
    }
}

  我们会发现，我们在Bank类的构造方法里面先是创建了ReetrantLock类的对象，然后通过ReetrantLock类的对象创建一个Condition的对象；然后我们在看一看reduce方法，在对count进行操作之前，我们先让多个线程来获得锁，获得锁之后，如果发现count不符合要求，那么久调用condition的await方法来将自己阻塞，并且释放锁，但是需要注意的是在还有一个signalAll方法。这个方法有什么用呢？我们待会再add方法。此时reduce方法的线程如果发现count不符合要求，就将自己阻塞掉，并且释放锁，如果此时被一个add方法里面的线程获得了锁，那就可以对count进行加100的操作。操作完毕之后会调用Condition的signalAll方法唤醒之前因为Condition.await方法而阻塞掉的线程。
  经过上面的学习，我们学习了到了两种方式来使得我们的程序到达同步要求。但是这两者有什么区别呢？

1. ReetrantLock对象是用来保护代码片段的，保证任何时刻只有一个线程执行一段代码。

2. ReetrantLock对象可以管理被保护段的线程。

3. 一个ReettrantLock对象可以拥有一个或者多个Condition的对象。

4. 每个Condition对象可以管理那些获得了锁但是不能正常的运行的线程。

4. 同步方法--synchronized关键字

  我们知道，在使用ReetrantLock对象来保证程序段的同步，往往需要lock和unLock，像这种操作容易使得程序出现问题，因为如果一个程序写了lock方法，但是没有unLock方法，这个是有问题。所以ReetrantLock会使得我们的程序错误性提高，而且在使用起来又比较的麻烦。为了解决这个问题，Java推出了synchronized关键字。
  例如，我们的代码可以改成这样：

public class Bank {
    private int count = 1000;

    public synchronized void reduce() {
        if(count >= 100) {
            count -= 100;
            System.out.println("reduce " + count);
        }
    }

    public int getCount() {
        return count;
    }
}

  同时synchronized关键字还能修饰静态的方法。但是此时同步的条件不一样了，普通的方法将当前的对象作为内部锁，静态方法将当前的类作为内部锁。
  与此同时，我们synchronized关键字还能修饰代码块，但是需要我们手动设置内部锁对象，通常我们使用的当前对象。例如：

    public void reduce() {
        synchronized (this) {
            if (count >= 100) {
                count -= 100;
                System.out.println("reduce " + count + " threadId = " + Thread.currentThread().getId());
            }
        }
    }