System.out.print（name.charAt（i））;
}
}
这种方式就相当于用this锁住整个方法内的代码块，如果用synchronized加在静态方法上，就相当于用Outputter.class锁住整个方法内的代码块。
使用synchronized在某些情况下会造成死锁。
使用synchronized修饰的方法或者代码块可以看成是一个原子操作。
每个锁对象都有两个队列，一个是就绪队列，一个是阻塞队列，就绪队列存储了将要获得锁的线程，阻塞队列存储了被阻塞的线程，当一个线程被唤醒（notify）后，才会进入到就绪队列，从而有了获取CPU执行时间的可能，反之，当一个线程被wait后，就会进入阻塞队列，等待下一次被唤醒。
上面例子中，当第一个线程执行输出方法时，获得同步锁，执行输出方法，恰好此时第二个线程也要执行输出方法，但发现同步锁没有被释放，第二个线程就会进入就绪队列，等待锁被释放。
一个线程执行互斥代码过程如下：
1.获得同步锁；
2.清空工作内存；
3.从主内存拷贝对象副本到工作内存；
4.执行代码（计算或者输出等）；
5.刷新主内存数据；
6.释放同步锁。
所以，synchronized关键字既保证了多线程的并发有序性，又保证了多线程的内存可见性。
除去synchronized关键字之外，增加语义后的volatile关键字提供了另一种实现同步的方法。
如果一个变量被volatile修饰，那么Java内存模型（主内存和线程工作内存）确保所有线程都可以看到一致的最新的该变量的值，来看一段代码：
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
classTest{
staticinti=0,j=0;
staticvoidwrite（）{
i+=10;
j+=5;
}
staticvoidread（）{
System.out.println（"i="+i+"j="+j）;
}
}
一些线程执行write方法，另一些线程执行read方法，read方法有可能打印出j的值比i的值更大，按照之前分析的线程执行过程分析一下：
1.将变量i从主内存拷贝到工作内存；
2.改变i的值；
3.刷新主内存数据；
4.将变量j从主内存拷贝到工作内存；
5.改变j的值；
6.刷新主内存数据；
这个时候执行read方法的线程先读取了主存i原来的值又读取了j更新后的值，这就导致了程序的输出不是我们预期的结果，要阻止这种不合理的行为的一种方式是在write方法和read方法前面加上synchronized修饰符：
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
classTest{
staticinti=0,j=0;
staticsynchronizedvoidwrite（）{
i+=10;
j+=5;
}
staticsynchronizedvoidread（）{
System.out.println（"i="+i+"j="+j）;
}
}
根据前面的分析，我们可以知道，这时write方法和read方法再也不会并发的执行了，i和j的值在主内存中会一直保持最新值供其他线程读取，并且read方法输出的也是一致的。
但是synchronized在保证了write方法和read方法不能并发执行的同时，也让多个线程的read方法不能并发执行，这样的同步太过”重量级“。
不利于提高read性能。
使用在共享变量前加上volatile实现同步的方法，能够提供更”轻量级“的同步：
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
classTest{
staticvolatileinti=0,j=0;
staticvoidwrite（）{
i+=10;
j+=5;
}
staticvoidread（）{
System.out.println（"i="+i+"j="+j）;
}
}
write方法和read方法还会并发的去执行，但是加上volatile可以将共享变量i和j的改变直接响应到主内存中，这样保证了主内存中i和j的值一致性，然而在执行read方法时，在read方法获取到i的值和获取到j的值中间的这段时间，write方法也许被执行了好多次，导致j的值会大于i的值。
所以volatile可以保证内存可见性，不能保证并发有序性。
Java中的volatile变量可以被看作是一种“程度较轻的synchronized”；与synchronized块相比，volatile变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是synchronized的一部分。
volatile变量具有synchronized的可见性特性，但是不具备原子特性。
这就是说线程能够自动发现volatile变量的最新值。
您只能在有限的一些情形下使用volatile变量替代锁。
要使volatile变量提供理想的线程安全，必须同时满足下面两个条件：
1、对变量的写操作不依赖于当前值。
2、该变量没有包含在具有其他变量的不变式中。
实际上，这些条件表明，可以被写入volatile变量的这些有效值独立于任何程序的状态，包括变量的当前状态。
第一个条件的限制使volatile变量不能用作线程安全计数器。
虽然增量操作（x++）看上去类似一个单独操作，实际上它是一个由读取－修改－写入操作序列组成的组合操作，必须以原子方式执行，而volatile不能提供必须的原子特性。
实现正确的操作需要使x的值在这个组合操作的期间保持不变，而volatile变量无法实现这点（然而，如果将值调整为只从单个线程写入，那么可以忽略第一个条件）。
大多数编程情形都会与这两个条件的其中之一冲突，使得volatile变量不能像synchronized那样普遍适用于实现线程安全。
在JDK5.0之前，如果没有参透volatile的使用场景，还是不要使用了，尽量用synchronized来处理同步问题，线程阻塞这玩意简单粗暴。
二、Lock框架实现同步
我们已经知道，synchronized是Java的关键字，是Java的内置特性，在JVM层面实现了对临界资源的同步互斥访问，但synchronized粒度有些大，在处理实际问题时存在诸多局限性，比如响应中断等。
Lock提供了比synchronized更广泛的锁操作，它能以更优雅的方式处理线程同步问题。
如果一个代码块被synchronized关键字修饰，当一个线程获取了对应的锁，并执行该代码块时，其他线程便只能一直等待直至占有锁的线程释放锁。
事实上，占有锁的线程释放锁一般会是以下三种情况之一：
1）占有锁的线程执行完了该代码块，然后释放对锁的占有；
2）占有锁线程执行发生异常，此时JVM会让线程自动释放锁；
3）占有锁线程进入WAITING状态从而释放锁，例如在该线程中调用wait（）方法等。
synchronized是Java语言的内置特性，可以轻松实现对临界资源的同步互斥访问。
那么，为什么还会出现Lock呢？
试考虑以下三种情况：
Case1：
在使用synchronized关键字的情形下，假如占有锁的线程由于要等待IO或者其他原因（比如调用sleep方法）被阻塞了，但是又没有释放锁，那么其他线程就只能一直等待，别无他法。
这会极大影响程序执行效率。
因此，就需要有一种机制可以不让等待的线程一直无期限地等待下去（比如只等待一定的时间（解决方案：
tryLock（longtime,TimeUnitunit））或者能够响应中断（解决方案：
lockInterruptibly（））），这种情况可以通过Lock解决。
Case2：
我们知道，当多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作也会发生冲突现象，但是读操作和读操作不会发生冲突现象。
但是如果采用synchronized关键字实现同步的话，就会导致一个问题，即当多个线程都只是进行读操作时，也只有一个线程在可以进行读操作，其他线程只能等待锁的释放而无法进行读操作。
因此，需要一种机制来使得当多个线程都只是进行读操作时，线程之间不会发生冲突。
同样地，Lock也可以解决这种情况（解决方案：
ReentrantReadWriteLock）。
Case3：
我们可以通过Lock得知线程有没有成功获取到锁（解决方案：
ReentrantLock），但这个是synchronized无法办到的。
上面提到的三种情形，我们都可以通过Lock来解决，但synchronized关键字却无能为力。
事实上，Lock是java.util.concurrent.locks包下的接口，Lock实现提供了比synchronized关键字更灵活、更广泛、粒度更细的锁操作，它能以更优雅的方式处理线程同步问题。
也就是说，Lock提供了比synchronized更多的功能。
但是要注意以下几点：
1）synchronized是Java的关键字，因此是Java的内置特性，是基于JVM层面实现的。
而Lock是一个Java接口，是基于JDK层面实现的，通过这个接口可以实现同步访问；
2）采用synchronized方式不需要用户去手动释放锁，当synchronized方法或者synchronized代码块执行完之后，系统会自动让线程释放对锁的占用；而Lock则必须要用户去手动释放锁（发生异常时，不会自动释放锁），如果没有主动释放锁，就有可能导致死锁现象。
2.1Lock接口
通过查看Lock的源码可知，Lock是一个接口：
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
publicinterfaceLock{
voidlock（）;
voidlockInterruptibly（）throwsInterruptedException;//可以响应中断
booleantryLock（）;
booleantryLock（longtime,TimeUnitunit）throwsInterruptedException;//可以响应中断
voidunlock（）;
ConditionnewCondition（）;
}
lock（）、tryLock（）、tryLock（longtime,TimeUnitunit）和lockInterruptibly（）都是用来获取锁的。
unLock（）方法是用来释放锁的。
newCondition（）返回绑定到此Lock的新的Condition实例，用于线程间的协作。
在Lock接口中声明了四个方法来获取锁，那么这四个方法有何区别呢？
首先，lock（）方法是平常使用得最多的一个方法，就是用来获取锁。
如果锁已被其他线程获取，则进行等待。
在前面已经讲到，如果采用Lock，必须主动去释放锁，并且在发生异常时，不会自动释放锁。
因此，一般来说，使用Lock必须在try…catch…块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被被释放，防止死锁的发生。
通常使用Lock来进行同步的话，是以下面这种形式去使用的：
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
Locklock=...;
lock.lock（）;
try{
//处理任务
}catch（Exceptionex）{
}finally{
lock.unlock（）;//释放锁
}
tryLock（）方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true；如果获取失败（即锁已被其他线程获取），则返回false，也就是说，这个方法无论如何都会立即返回（在拿不到锁时不会一直在那等待）。
tryLock（longtime,TimeUnitunit）方法和tryLock（）方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false，同时可以响应中断。
如果一开始拿到锁或者在等待期间内拿到了锁，则返回true。
一般情况下，通过tryLock来获取锁时是这样使用的：
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
Locklock=...;
if（lock.tryLock（））{
try{
//处理任务
}catch（Exceptionex）{
}finally{
lock.unlock（）;//释放锁
}
}else{
//如果不能获取锁，则直接做其他事情
}
lockInterruptibly（）方法比较特殊，当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。
例如，当两个线程A与B同时通过lock.lockInterruptibly（）想获取某个锁时，假若此时线程A获取到了锁，而线程B只能继续等待，那么对线程B调用threadB.interrupt（）方法就能够中断线程B的等待过程。
所以lock.lockInterruptibly（）必须放在try块中或者在调用lockInterruptibly（）的方法外声明抛出InterruptedException，但推荐使用后者，原因稍后阐述。
因此，lockInterruptibly（）一般的使用形式如下：
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
publicvoidmethod（）throwsInterruptedException{pre">//将异常抛出，交给上层调用者处理
lock.lockInterruptibly（）;
try{
//.....
}
finally{
lock.unlock（）;
}
}
注意，当一个线程获取了锁之后，是不会被interrupt（）方法中断的。
因为interrupt（）方法只能中断阻塞过程中的线程而不能中断正在运行过程中的线程。
因此，当通过lockInterruptibly（）方法获取某个锁时，如果不能获取到，那么只有在继续等待的情况下，才可以响应中断的。
使用synchronized获取锁，当一个线程处于等待某个锁的状态时，是无法被中断的，只有一直等待下去。
需要特别注意的是，在使用Lock时，无论以哪种方式获取锁，习惯上最好一律将获取锁的代码放到try…catch…，因为我们一般将锁的unlock操作放到finally子句中，如果线程没有获取到锁，在执行finally子句时，就会执行unlock操作，从而抛出IllegalMonitorStateException，因为该线程并未获得到锁却执行了解锁操作。
2.2、ReentrantLock
ReentrantLock，即可重入锁。
ReentrantLock是唯一实现了Lock接口的类，并且ReentrantLock提供了更多的方法。
下面通过一些实例学习如何使用ReentrantLock。
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
publicclassTest{
privateArrayListarrayList=newArrayList（）;
publicstaticvoidmain（String[]args）{
finalTesttest=newTest（）;
newThread（"A"）{
publicvoidrun（）{
test.insert（Thread.currentThread（））;
};
}.start（）;
newThread（"B"）{
publicvoidrun（）{
test.insert（Thread.currentThread（））;
};
}.start（）;
}
publicvoidinsert（Threadthread）{
Locklock=newReentrantLock（）;//注意这个地方:
lock被声明为局部变量
lock.lock（）;
try{
System.out.println（"线程"+thread.getName（）+"得到了锁..."）;
for（inti=0;i<5;i++）{
arrayList.add（i）;
}
}catch（Exceptione）{
}finally{
System.out.println（"线程"+thread.getName（）+"释放了锁..."）;
lock.unlock（）;
}
}
}
运行结果：
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
线程A得到了锁...
线程B得到了锁...
线程A释放了锁...
线程B释放了锁...
结果或许让人觉得诧异。
第二个线程怎么会在第一个线程释放锁之前得到了锁？
原因在于，在insert方法中的lock变量是局部变量，每个线程执行该方法时都会保存一个副本，那么每个线程执行到lock.lock（）处获取的是不同的锁，所以就不会对临界资源形成同步互斥访问。
因此，我们只需要将lock声明为成员变量即可，代码修改如下所示。
[java]viewplaincopy在CODE上查看代码片派生到我的代码片
publicclassTest{
privateArrayListarrayList=newArrayList（）;
privateLocklock=newReentrantLock（）;//注意这个地方:
lock被声明为成员变量
...
}
修改后的运行结果：
[java]viewplaincopy在CODE上查看代码片派生到我
升级会员 