Java线程同步问题在实践中寻找答案

Java线程同步需要我们不断的学习，在学习的时候我们会遇到不少的问题，其实我们在前面讲了为什么要Java线程同步，下面我们就来看如何才能线程同步  。希望我们大家有所收获  。

Java线程同步的基本实现思路还是比较容易理解的  。我们可以给共享资源加一把锁，这把锁只有一把钥匙  。哪个线程获取了这把钥匙，才有权利访问该共享资源  。生活中，我们也可能会遇到这样的例子  。一些超市的外面提供了一些自动储物箱  。每个储物箱都有一把锁，一把钥匙  。人们可以使用那些带有钥匙的储物箱，把东西放到储物箱里面，把储物箱锁上，然后把钥匙拿走  。这样，该储物箱就被锁住了，其他人不能再访问这个储物箱  。（当然，真实的储物箱钥匙是可以被人拿走复制的，所以不要把贵重物品放在超市的储物箱里面  。于是很多超市都采用了电子密码锁  。）

Java线程同步锁这个模型看起来很直观  。但是，还有一个严峻的问题没有解决，这个同步锁应该加在哪里？ 当然是加在共享资源上了  。反应快的读者一定会抢先回答  。

没错，如果可能，我们当然尽量把同步锁加在共享资源上  。一些比较完善的共享资源，比如，文件系统，数据库系统等，自身都提供了比较完善的同步锁机制  。我们不用另外给这些资源加锁，这些资源自己就有锁  。

但是，大部分情况下，我们在代码中访问的共享资源都是比较简单的共享对象  。这些对象里面没有地方让我们加锁  。读者可能会提出建议：为什么不在每一个对象内部都增加一个新的区域，专门用来加锁呢？这种设计理论上当然也是可行的  。问题在于，Java线程同步的情况并不是很普遍  。如果因为这小概率事件，在所有对象内部都开辟一块锁空间，将会带来极大的空间浪费  。得不偿失  。

于是，现代的编程语言的设计思路都是把同步锁加在代码段上  。确切的说，是把同步锁加在“访问共享资源的代码段”上  。这一点一定要记住，同步锁是加在代码段上的  。

同步锁加在代码段上，就很好地解决了上述的空间浪费问题  。但是却增加了模型的复杂度，也增加了我们的理解难度  。现在我们就来仔细分析“同步锁加在代码段上”的Java线程同步模型  。

首先，我们已经解决了同步锁加在哪里的问题  。我们已经确定，同步锁不是加在共享资源上，而是加在访问共享资源的代码段上  。

其次，我们要解决的问题是，我们应该在代码段上加什么样的锁  。这个问题是重点中的重点  。这是我们尤其要注意的问题：访问同一份共享资源的不同代码段，应该加上同一个同步锁；如果加的是不同的同步锁，那么根本就起不到同步的作用，没有任何意义  。

这就是说，同步锁本身也一定是多个线程之间的共享对象  。