引言

在《Java Concurrency in Practice》的加锁机制一节中作者提到：

    Java提供一种内置的锁机制来支持原子性：同步代码块。“重入”意味着获取锁的操作的粒度是“线程”，而不是调用。当某个线程请求一个由其他线程持有的锁时，发出请求的线程就会阻塞。然而，由于内置锁时可重入的，因此如果某个线程试图获得一个已经由它自己持有的锁，那么这个请求就会成功。————《Java Concurrency in Practice》

关于上面引述的这段话，出自书中第21页，但是从书中给出的例子来看，对于这个概念真的很难理解，有很多问题blowed my mind。而最重要的关键，当然是“同一个线程”。

而锁这个东西，我们在程序中需要通过其他的线程来感知锁的存在，否则如果我用一个线程执行了一个用synchronized修饰的方法，谁来证明锁的存在？这也是测试代码的书写难点。

测试代码

public class Test {public static void main(String[] args) throws InterruptedException {// 创建一个子类对象final Child widget = new Child();// 定义线程1Thread th1 = new Thread("th1") {@Overridepublic void run() {System.out.println(super.getName() + ":start...");widget.doSometing();}};// 定义线程2Thread th2 = new Thread("th2") {@Overridepublic void run() {System.out.println(super.getName() + ":start...");/*** 下行在th1刚刚调用子类重写的父类加锁方法doSometing()时，* 另一个线程th2直接调用父类的其他加锁方法会出现等待现象，说明th1调用子类中重写的加锁方法会立刻持有父类锁，* 此时不允许调用父类其他的加锁方法*/widget.doAnother();/*** 下行在th1开始调用子类重写的父类加锁方法后，立刻通过另一个线程th2调用父类的未加锁方法doNother()，* th2会立刻执行完毕，不需要等待，也就 证明了内置锁对那些没有加锁的方法是不起作用的，也就是说这些没有加锁的方法，* 不会因为其他线程持有该类的内置锁就处于等待或阻塞的状态而无法执行*/// widget.doNother();/*** 如果说调用doAnother证明了调用重写的父类加锁方法会直接持有父类锁的话，* 那么下行就证明了调用子类的加锁方法也一定会获得该类的内置锁，就算这个方法已经* 持有了父类锁，也就是说线程th1在执行doSomething()之初就持有了子类锁和父类锁两个锁，*/// widget.doMyLike();/** th2调用doSometing()是需要等待的，并不是继承的关系，不是重入，重入是发生在一个线程中的 */// widget.doSometing();}};th1.start();Thread.sleep(100);th2.start();}
}class Father {/** 唯一被子类Child重写的方法 */public synchronized void doSometing() {System.out.println(Thread.currentThread().getName() + ":Father ... do something...");}public synchronized void doAnother() {System.out.println(Thread.currentThread().getName() + ":Father... do another thing...");}public void doNother() {System.out.println(Thread.currentThread().getName() + ":Father... do Nothing...");}
}class Child extends Father {@Overridepublic synchronized void doSometing() {try {System.out.println(Thread.currentThread().getName() + ":Child do something...");Thread.sleep(5000);System.out.println(Thread.currentThread().getName() + ":end Child do something...");} catch (InterruptedException e) {e.printStackTrace();}super.doSometing();}public synchronized void doMyLike() {System.out.println(Thread.currentThread().getName() + ":Child do my like...");}
}

这是补充了网上代码的测试code，重要的地方都写了注释，原版代码可以参考这篇文章《java内置锁synchronized的可重入性》

 

这段代码其实是书中程序清单2-7的代码扩展和补充，参考文章的例子非常给力，不过还是需要花点头脑去理解和总结（不过诸位放心，本篇文章绝对不是简单的拿来主义）。

 

测试code想要表达什么？在main方法中声明了两个线程，用th1去制造“可重入”的条件，而th2用于感知锁的存在。我们说可重入是指同一个线程而言。但是同一个线程如何才可以持有了一个类的锁后又去调用加锁代码块？

就像上述代码所示：父类的加锁方法doSomething()被子类重写了，不仅重写了，还又加了个锁。那么th1在调用子类doSomething()方法的时候，不仅会获得子类的锁，还会同时获得一个父类的锁，也就是说doSomething()在被th1的调用之初，th1就会立刻获得子类和父类两个类的内置锁。

而一个线程持有了这个类的内置锁导致的结果是，其他线程需要等待或阻塞执行该类中其他任何加锁方法，但未加锁方法不受影响！

因此，根据这个代码规则，th1此时持有了子类锁和父类锁，那么th2在执行父类的doAnother()加锁方法时就会出现阻塞执行的情况。

但是我突然又有一个想法，为何一个线程同时获得子类和父类的双重锁的条件这么多？如果子类的重写方法没有锁呢？如果父类的方法没有锁，子类重写的方法有锁呢？这些情况又会是怎样的执行结果？于是我调整了代码，将这两种情况重现测试了一下：

情况一：父类加锁，子类未加锁，th1调用子类重写方法：

父类：

子类：

执行结果：

情况二：父类方法未加锁，子类重写后加锁，th1调用子类重写的该方法。

父类：

子类：

执行结果：

总结：子类重写了父类方法时，如果子类该方法有同步锁，那么不论父类该方法是否加锁，线程在调用子类的这个方法时都会同时获得子类和父类双重锁，从而影响其他线程调用子类和父类中任何加锁方法。

（说实话，如果是gif动图，效果会更明显一些，因为在子类重写的doSomething()中，有一个5秒的线程睡眠时间，这样的测试效果是比较直观的。)

以上就是关于“重入”的引申理解，即关于线程获得双重锁的知识总结，可能有些绕，而且后面的扩展总结也比较难想到，笔者建议将上面的完整代码考下来运行一下，体会一下。而且笔者在必要的输出语句上补充了线程信息，类名信息，便于区分输出结果和执行顺序，线程的睡眠时间也做了调整，便于理解，注释也尽量做到严谨概括。其中最重要的是th2定义中的4种情况，当然可能还有其他的情况我没有列举出来，比如子类新增一个同步方法，在th1中调用的时候是否也会获得父类的内置锁呢？大家可以去尝试一下。

总之，再次强调，一旦线程获得了某个类的内置锁，其他线程便会阻塞执行该类中的任何同步方法，但该类的非同步方法是不受影响的。

如有疑问，欢迎文末留言！

=======2018.6.21 清晨更新=======================================================

经过检验测试，如果子类中新增一个同步方法，例如前面代码中的synchronized doMyLike()，线程th1调用之后依然获取了子类和父类双重锁。

这样我们就将前面的概念上升到了更广泛的高度上：

如果一个线程调用了一个对象的同步方法，那么这个线程不仅持有该类对象的锁，由于子类对象同时也是父类对象，因此其他线程不能访问父类中其他的同步方法，使其他线程进入阻塞状态。