Java Notes: Synchronized的类锁和对象锁以及谈谈线性安全类

synchronized是Java实现互斥锁的关键词也是一种悲观锁。因为这是一个重量级操作，它对性能最大的影响是阻塞的是实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性带来了很大的压力。

首先，我们需要明确一点认识：任何对象都存在一把锁。如果对象是一个人，那么锁就像ta保管的钥匙，有且只有唯一一根。这就是对象锁，而这把钥匙则是其同步块代码的通行权。

如果一段代码被synchronized(object)包围了，证明一个线程如果想要执行这段代码，它要首先拿到object的钥匙。如果这把钥匙被其它的线程拿走了，那你就只能等其它的线程把这把钥匙换回来。

如果object1和object2属于同一类的不同对象，那么如果有线程拿了synchronized(object1)的锁，而你这个线程想运行synchronized(object2)的代码，是没有问题的。因为它们不属于同一个锁保护的，就是说钥匙不同，有2把。

对象锁还有其它两种常见的声明方式：1）synchronized(this) 或者 2) synchronized修饰的方法。

那么类锁呢？类锁只是一种特殊的对象锁。其返回的是Class对象的锁。声明语法是：static synchronized修饰的方法 或者 synchronized(classname.class). 

其实，本质上而言，synchronized(object)或者synchronized(**.class)一个代码块和synchronized一个方法或者static是可以互通的的。方法同步锁的本质可以是：

public void func(){
  synchronized(object){
     ...
  }
}

其实就是把函数内的代码块同步了。上述代码等价于：

public synchronized void func(){
    ...

}

线性安全类真的线性安全吗？

有一个很有趣的现象，在多线程的环境当中，优先选择使用线性不安全类。为什么？

线性安全类的意思是，其中所有的方法都是加了对象级同步锁的。然而，光光是方法加了同步锁是远远不够的，举个例子，看看以下代码：

众所周知，Vector是线性安全的，与之相对的，ArrayList是线性不安全的。那为什么我们很少看到用Vector呢？很重要的原因是，因为Vector不遵循于Collection.List的接口，一开始并没有add等众所周知的结果，后来我猜测使用了适配器模式开发了类似的接口。其次，与HashTable不够HashMap普及的原因一致，线性安全的类会更慢，效率更低（同步锁的原因），而且当只有一个线程的时候，就没必要使用线性安全类了。

现在，来说说另外一个原因：当在多线程环境中，也不推荐使用线性安全类。

原因见上图，contains方法是同步的，add方法也是同步的，但是假设有这么个情况，一个进程获得了contains的同步锁，判断返回false后，正准备执行add的时候被JVM切换到了另外一个线程，这时候另外一个线程获得了contains的同步锁，判断同样返回false。然后成功add了。接着刚刚的那个线程轮到它执行的时候，也会add同一个元素。

这是因为两个线程安全的方法之间，并没有任何的方法确保线程同步。所以，就算Vector，你还是需要在if的前面加上synchronized(myVector)的。与其加两次锁，还不如直接使用ArrayList用一次加锁来得直接。