我们知道在多线程编程中，我们很大的一部分内容是为了解决线程间的资源同步问题和线程间共同协作解决问题。线程间的同步，通俗我们理解为僧多粥少，在粥有限情况下，我们怎么去防止大家有秩序的喝到粥，不至于哄抢都没得喝。线程讲协作，我们可以理解为我们在医院看病的时候，我们要先挂号，才能看病。现在医院有很多病人排队，怎么协调病人都有秩序的先挂号，后看病。本篇文章的重点不在此，也不是在此一下子能分析完，我们先从Java JVM的角度来理解多线程的一些方面。
我们知道多线程间的数据同步，我们是通过加锁的操作来实现的。线程间的锁是怎么体现的？首先，我们看Java线程都需要对什么样的数据进行处理。我们顺便简单介绍下关于Java线程内存分配。
首先，Java程序的数据分配的最小单位是进程，在进程里至少会有一个主线程，线程间是可以进行数据共享的。但是，我们的每个线程还有属于自己的线程栈，所以，Java线程不需要去考虑每个线程的私有线程栈里的私有数据。如：类的对象中非同步方法或者（代码块中定义的临时变量），他们在线程栈中分配内存，由于他们是方法中定义的临时变量，其他对象根本获得不了它的内存，所以，也就不用去考虑对这类数的同步。
我们简单总结至少有以下两类数据在多个线程访问的时候，我们需要考虑数据同步：1.存在堆中的类的实例；2.类的方法作用域中的类变量。
所以，我们的多个线程有可能会同时访问这两类数据的时候，我们需要给它们加上锁，先到先得的每次只准单一访问。通过学习我们知道，Java中的对象的锁是排他锁，每个类和对象都会有对应的锁。我们在平时编程中，常用触发锁的方式是通过互斥量的方式来同步共享资源，使得对代码块的访问每次都只允许一个对象访问。在Java语法中，我们至少有两种方式来同步代码块来对共享资源进行同步，如：synchronized 和ReentrantLock上锁的方式。
关于Synchronized和ReenTrantLock的一点认识
关于synchronized 和ReentrantLock的性能讨论很多文章说法不一，有一种说法，JavaSE 的java.util.concurrent中ReentrantLock的设计就是对synchronized的替代方案，性能更好（http://www.ibm.com/developerworks/cn/java/j-jtp10264/index.html），也有一种说法，在JDK 1.6后，两个并没有性能的差别（《Java Concurrency In Pratice》）。但是有点，我们必须可以统一认识，使用ReetrantLock，在设计上弥补了synchronized存在的一些不足，至少在设计上有两点我们可以看出ReetrantLock对synchronized的改进：
1.ReetrantLock能方便捕捉上锁的代码块的异常，代码如下：
Lock lock = new ReentrantLock();
...
lock.lock();
try {
// 对锁定对象进行更新等操作
} finally {
lock.unlock();
}
2.ReetrantLock实现了中断的锁机制，synchronized加锁线程可能一直无限制的等待下去，就算那些正在占用资源的线程死锁了，正在等待的那些资源还是会继续等待，但是ReentrantLock可以选择放弃等待（该方法lockInterruptibly()的实现）。ReetrantLock应用可以举例说明：如果A、B2个线程去竞争锁，A线程得到了锁，B线程等待，但是A线程这个时候实在有太多事情要处理，就是一直不返回，B线程可能就会等不及了，想中断自己，不再等待这个锁了，转而处理其他事情。这个时候ReentrantLock就提供了2种机制，第一，B线程中断自己（或者别的线程中断它），但是ReentrantLock不去响应，继续让B线程等待，你再怎么中断，我全当耳边风（synchronized原语就是如此）；第二，B线程中断自己（或者别的线程中断它），ReentrantLock处理了这个中断，并且不再等待这个锁的到来，完全放弃。