Java多线程学习总结（二）
线程同步（一）
（1）竞争条件（race condition）
在多数多线程应用中，两个或两个以上的线程需要共享对通一数据的存取，如果两个线程存取相同的对象，并且每一个线程都调用了一个修改该对象的方法，将会产生讹误的对象。
（2）常见的竞争条件例子有：转账
（3）解决竞争条件的方法——锁对象
利用synchronized关键字来给方法加锁；JDK1.5以后可以使用ReentrantLock类来对代码块加锁。使用ReentrantLock代码块的基本结构如下：
lock.lock(); try { //critical section } finally { lock.unlock(); }
这一结构能确保任何时刻都只有一个线程进入临界区，一旦一个线程封锁了锁对象，其他任何线程都无法通过lock语句，当其他线程调用lock时，它们被阻塞，直到第一个线程释放锁对象。即当第一个线程释放锁时，第二个线程才能开始运行。
锁是可重入的，因为线程可以重复地获得已经持有的锁，锁保持一个持有计数器来跟踪对lock方法的嵌套调用；线程在每一次调用lock都要调用unlock来释放锁，由于这一特性，被一个锁保护的代码可以调用另一个使用相同锁的方法。
（4）条件对象
通常，线程进入临界区，却发现在某一条件满足后它才能执行，要使用一个条件对象来管理那些已经获得了一个锁但是不能做有用工作的线程。
就拿转账作为一个例子：通常，我们要避免选择没有足够资金的账户作为转出账户，所以转账之前要判断一些用户当前的余额是否是大于转出金额。
if(bank.getBalance(account)>=amount){//判断 bank.transfer(account,otherAccount,amount);//转账 }
看看这样有什么问题？假设当前线程通过了判断，但是在调用转账方法之前被阻塞了（此时有另外一个线程在对账户进行的余额进行修改），当这个线程获得锁时，调用转账方法，发现自己的余额小于了转账金额，但却又继续执行转账方法，这就使得程序出现了错误。那么应该如何解决呢？
可以使用锁来保护检查与转账动作来做到：
public void transfer(int account,int otherAccount,int amount){ lock.lock(); try { while (bank.getBalance(account)<amount){ //等待 } //转账方法 }finally { lock.unlock(); } }
while循环的作用是：当前账户的余额小于转账金额时，就一直等待另外一个线程向该账户注入足够的金额。一旦该账户的金额足够了，就退出while循环，继续执行转账的核心方法。但是，当前的线程刚刚获得了对lock的排他性，因此别的线程没有进行存款操作的机会，这应该怎么处理呢？现在就引入条件对象了。
class Bank{ //... private Condition sufficientFunds;//条件对象，在java.util.concurrent.locks包下; private Lock bankLock=new ReentrantLock(); //... public Bank(){ //... sufficientFunds=bankLock.newCondition(); //... } }
如果调用transfer方法时发现余额不足，就可以调用sufficientFunds.await()方法，当前线程被阻塞了，并放弃了锁，这样就可以等另一个线程来修改账户的余额了。
一旦一个线程调用await方法，它进入该条件的等待集，当锁可用时，该线程继续阻塞，直到另一个线程调用同一条件对象的signalAll方法为止。这一调用会重新激活因为这一条件而等待的所以线程，这些线程会从await调用中返回，获得可用的锁并从被阻塞的地方继续执行。
注意： 当一个线程调用await时，它没有办法重新激活自身，需要等待其他线程来激活它；如果没有线程来激活它，那它就永不会执行了，这会导致死锁现象。那么应该何时调用signalAll呢？在对象的状态有利于等待线程的方向改变时调用signalAll，例如，当一个账户余额发生改变时，等待的线程会又机会检查余额。在刚才的例子中，完成转账时，调用signalAll方法。
public void transfer(int account,int otherAccount,int amount){ lock.lock(); try { while (bank.getBalance(account)<amount){ sufficientFunds.await();//等待 } /*转账方法 ...... */ sufficientFunds.signalAll(); }finally { lock.unlock(); } }
注意： 调用signalAll()方法不会立即激活一个等待线程，它仅仅是解除等待线程的阻塞，以便这些线程可用在当前线程退出同步方法之后通过竞争实现对对象的访问。
另外一个方法是signal，它会随机接触等待集中某个线程的阻塞状态。如果被选择的线程发现自己不能运行，那么它再次被阻塞，如果没有其他线程调用signal，那么系统就死锁了
（5）synchronized关键字
先总结一下有关锁和条件的关键：
锁原来保护代码片段，任何时刻只能由一个线程执行被保护的代码
锁可用管理试图进入被保护代码段的线程
锁可用拥有一个或多个相关的条件对象
每个条件对象管理那些已经进入被保护的代码段但还不能运行的线程
从jdk1.0开始，Java中的每一个对象都有一个内部锁，如果一个方法永synchronized关键字声明，那么对象的锁将保护整个方法。即要调用该方法，线程必须先获得内部的对象锁。
public synchronized void method(){ // }
内部对象锁只有一个相关条件。wait方法添加一个线程到等待集中，notifyAll或notify方法解除等待线程的阻塞状态。
注意，笔试常考：wait，notifyAll，notify方法是Object类的final方法。
可以使用synchronized关键字对上面的转账方法进行改造：
public synchronized void transfer(int account,int otherAccount,int amount){ while (bank.getBalance(account)<amount){ wait();//等待 } /*转账方法 ...... */ notifyAll(); }
可以将静态方法声明为synchronized，如果调用这种方法，该方法会获得相关的类对象的内部锁。如Bank.class对象的锁会被锁住，此时，没有其他线程可以调用同一个类的这个或任何其他的同步静态方法。
内部锁和条件存在一些局限：
不能中断一个正在试图获得锁的线程
试图获得锁时不能设定超时
每个锁仅有单一的条件，可能是不够的
那么是使用Lock/Condition还是使用synchronized呢？
最好既不使用Lock/Condition也不使用synchronized。在多数情况下，可以使用java.util.concurrent包中的机制，后续的博客会总结到。
如果使用synchronized合适，就尽量用synchronized，这样可以减少代码数量，减少出错几率。
如果需要使用Lock/Condition的独有特性时，才用Lock/Condition。
