对java中synchronized的认识

使用情况的归纳

synchronized的使用分为两种情形，一种是synchronized方法，另外一种是synchronized代码块。

synchronized方法

synchronized方法是控制对成员变量的访问，这里又分别分为对类普通成员变量和对类的静态成员变量的控制。

当synchronized修饰的是成员方法时，每个类实例对应一把锁，每个 synchronized 方法都必须获得调用该方法的类实例的锁方能执行，否则所属线程阻塞，方法一旦执行，就独占该锁，直到从该方法返回时才将锁释放，此后被阻塞的线程方能获得该锁，重新进入可执行状态。这种机制确保了同一时刻对于每一个类实例，其所有声明为 synchronized 的成员函数中至多只有一个处于可执行状态（因为至多只有一个能够获得该类实例对应的锁），从而有效避免了类成员变量的访问冲突（只要所有可能访问类成员变量的方法均被声明为 synchronized）

同样的当synchronized修饰的是静态成员方法时，只是对应的实例变成了类本身而已。

很明显，我们知道这如果都这么处理，就会有一个很大的缺陷。因为我们知道synchronized同步是很消耗资源的，底层为了能够达到同步，是做了很多的判断的。这样就大大的影响了效率。为此就有了当synchronized块这个概念。

synchronized代码块

synchronized 块是这样一个代码块，其中的代码必须获得对象 syncObject （如前所述，可以是类实例或类）的锁方能执行，具体机制同前所述。由于可以针对任意代码块，且可任意指定上锁的对象，故灵活性较高。对synchronized(this)的一些理解 ，有以下这么几点：

当两个并发线程访问同一个对象object中的这个synchronized(this)同步代码块时，一个时间内只能有一个线程得到执行。另一个线程必须等待当前线程执行完这个代码块以后才能执行该代码块。

简单点，就是说，如果我们把对象锁当作开门的钥匙，代码块当作是门的话，因为只有一把钥匙，所以每次都只能是一个人使用这把钥匙去开门，完了之后，再归还，这样另外的人才能用这把钥匙。

当一个线程访问object的一个synchronized(this)同步代码块时，另一个线程仍然可以访问该object中的非synchronized(this)同步代码块。

简单点，就是说，当一个人去那间有钥匙的门的房间时，其它的人可以进入到其它的不用钥匙的房间。

当一个线程访问object的一个synchronized(this)同步代码块时，其他线程对object中所有其它synchronized(this)同步代码块的访问将被阻塞。也就是说，当一个线程访问object的一个synchronized(this)同步代码块时，它就获得了这个object的对象锁。结果，其它线程对该object对象所有同步代码部分的访问都被暂时阻塞。

简单点，就是说，当一个人去那间有钥匙的门的房间时，所有其它想要这把钥匙的开门的人都必须等这个人用完后，才能重新获取这把钥匙，因为钥匙只有一把。

一个简单的比喻

一个object就像一个大房子，大门永远打开。房子里有 很多房间（也就是方法）。

这些房间有上锁的（synchronized方法）， 和不上锁之分（普通方法）。房门口放着一把钥匙（key），这把钥匙可以打开所有上锁的房间。

另外我把所有想调用该对象方法的线程比喻成想进入这房子某个 房间的人。所有的东西就这么多了，下面我们看看这些东西之间如何作用的。

在此我们先来明确一下我们的前提条件。该对象至少有一个synchronized方法，否则这个key还有啥意义。当然也就不会有我们的这个主题了。

一个人想进入某间上了锁的房间，他来到房子门口，看见钥匙在那儿（说明暂时还没有其他人要使用上锁的 房间）。于是他走上去拿到了钥匙，并且按照自己 的计划使用那些房间。注意一点，他每次使用完一次上锁的房间后会马上把钥匙还回去。即使他要连续使用两间上锁的房间，中间他也要把钥匙还回去，再取回来。

因此，普通情况下钥匙的使用原则是：“随用随借，用完即还。”

这时其他人可以不受限制的使用那些不上锁的房间，一个人用一间可以，两个人用一间也可以，没限制。但是如果当某个人想要进入上锁的房

间，他就要跑到大门口去看看了。有钥匙当然拿了就走，没有的话，就只能等了。

要是很多人在等这把钥匙，等钥匙还回来以后，谁会优先得到钥匙？Not guaranteed。象前面例子里那个想连续使用两个上锁房间的家伙，他中间还钥匙的时候如果还有其他人在等钥匙，那么没有任何保证这家伙能再次拿到。

鸣谢

巴山夜雨