第15讲 | Java的synchronized和ReentrantLock有什么区别呢？（转、重排）

从今天开始，我们将进入Java并发学习阶段。软件并发已经成为现代软件开发的基础能力，而Java精心设计的高效并发机制，正是构建大规模应用的基础之一，所以考察并发基本功也成为各个公司面试Java工程师的必选项。

今天我要问你的问题是， synchronized和ReentrantLock有什么区别？有人说synchronized最慢，这话靠谱吗？

典型回答

synchronized是Java内建的同步机制，所以也有人称其为Intrinsic Locking，它提供了互斥的语义和可见性，当一个线程已经获取当前锁时，其他试图获取的线程只能等待或者阻塞在那里。

在Java 5以前，synchronized是仅有的同步手段，在代码中， synchronized可以用来修饰方法，也可以使用在特定的代码块儿上，本质上synchronized方法等同于把方法全部语句用synchronized块包起来。

reentrant   re entrant
美 [rɪ'entrənt]
英 [riː'entrənt]
adj.【建】凹角(的)；再进去(的)
网络可重入；可再入的；可重入的

ReentrantLock，通常翻译为再入锁，是Java 5提供的锁实现，它的语义和synchronized基本相同。再入锁通过代码直接调用lock()方法获取，代码书写也更加灵活。与此同时，ReentrantLock提供了很多实用的方法，能够实现很多synchronized无法做到的细节控制，比如可以控制fairness，就是控制公平性，或者利用定义条件等。但是，编码中也需要注意，必须要明确调用unlock()方法释放，不然就会一直持有该锁。

synchronized和ReentrantLock的性能不能一概而论，早期版本synchronized在很多场景下性能相差较大，在后续版本进行了较多改进，在低竞争场景中表现可能优于ReentrantLock。

考点分析

今天的题目是考察并发编程的常见基础题，我给出的典型回答算是一个相对全面的总结。

对于并发编程，不同公司或者面试官面试风格也不一样，有个别大厂喜欢一直追问你相关机制的扩展或者底层，有的喜欢从实用角度出发，所以你在准备并发编程方面需要一定的耐心。

我认为，锁作为并发的基础工具之一，你至少需要掌握：

• 理解什么是线程安全。

• synchronized、ReentrantLock等机制的基本使用与案例。

更近一步，你还需要：

• 掌握synchronized、ReentrantLock底层实现；理解锁膨胀、降级；理解偏斜锁、自旋锁、轻量级锁、重量级锁等概念。

掌握并发包中java.util.concurrent.lock各种不同实现和案例分析。

知识扩展

专栏前面几期穿插了一些并发的概念，有同学反馈理解起来有点困难，尤其对一些并发相关概念比较陌生，所以在这一讲，我也对会一些基础的概念进行补充。

首先，我们需要理解什么是线程安全。

我建议阅读Brain Goetz等专家撰写的《Java并发编程实战》（Java Concurrency in Practice），虽然可能稍显学究，但不可否认这是一本非常系统和全面的Java并发编程书籍。按照其中的定义，线程安全是一个多线程环境下正确性的概念，也就是保证多线程环境下共享的、可修改的状态的正确性，这里的状态反映在程序中其实可以看作是数据。

换个角度来看，如果状态不是共享的，或者不是可修改的，也就不存在线程安全问题，进而可以推理出保证线程安全的两个办法：

• 封装：通过封装，我们可以将对象内部状态隐藏、保护起来。

• 不可变：还记得final和immutable吗，就是这个道理，Java语言目前还没有真正意义上的原生不可变，但是未来也许会引入。

线程安全需要保证几个基本特性：

• 原子性，简单说就是相关操作不会中途被其他线程干扰，一般通过同步机制实现。

• 可见性，是一个线程修改了某个共享变量，其状态能够立即被其他线程知晓，通常被解释为将线程本地状态反映到主内存上，volatile就是负责保证可见性的。

• 有序性，是保证线程内串行语义，避免指令重排等。

可能有点晦涩，那么我们看看下面的代码段，分析一下原子性需求体现在哪里。这个例子通过取两次数值然后进行对比，来模拟两次对共享状态的操作。

你可以编译并执行，可以看到，仅仅是两个线程的低度并发，就非常容易碰到former和latter不相等的情况。这是因为，在两次取值的过程中，其他线程可能已经修改了sharedState。

public class ThreadSafeSample {
	public int sharedState;

	public void nonSafeAction() {
		while (sharedState < 100000) {
			int former = sharedState++;
			int latter = sharedState;
			if (former != latter - 1) {
				Sysem.out.printf("Observed data race, former is " +
				former + ", " + "latter is " + latter);
			}
		}
	}

	public satic void main(String[] args) throws InterruptedException {
		ThreadSafeSample sample = new ThreadSafeSample();
		Thread threadA = new Thread(){
			public void run(){
				sample.nonSafeAction();
			}
		};
		
		Thread threadB = new Thread(){
			public void run(){
				sample.nonSafeAction();
			}
		};
		threadA.sart();
		threadB.sart();
		threadA.join();
		threadB.join();
	}
}

下面是在我的电脑上的运行结果：

C:>c:\jdk-9\bin\java ThreadSafeSample

Observed data race, former is 13097, latter is 13099

synchronized

将两次赋值过程用synchronized保护起来，使用this作为互斥单元，就可以避免别的线程并发的去修改sharedState。

synchronized (this) {
	int former = sharedState ++;
	int latter = sharedState;
	// …
}

如果用javap反编译，可以看到类似片段，利用monitorenter/monitorexit对实现了同步的语义：

11: asore_1
12: monitorenter
13: aload_0
14: dup
15: getfeld #2
// Field sharedState:I
18: dup_x1
…
56: monitorexit

我会在下一讲，对synchronized和其他锁实现的更多底层细节进行深入分析。

代码中使用synchronized非常便利，如果用来修饰静态方法，其等同于利用下面代码将方法体囊括进来：

synchronized (ClassName.class) {}

ReentrantLock

再来看看ReentrantLock。你可能好奇什么是再入？它是表示当一个线程试图获取一个它已经获取的锁时，这个获取动作就自动成功，这是对锁获取粒度的一个概念，也就是锁的持有是以线程为单位而不是基于调用次数。Java锁实现强调再入性是为了和pthread的行为进行区分。

再入锁可以设置公平性（fairness），我们可在创建再入锁时选择是否是公平的。

ReentrantLock fairLock = new ReentrantLock(true);

这里所谓的公平性是指在竞争场景中，当公平性为真时，会倾向于将锁赋予等待时间最久的线程。公平性是减少线程“饥饿”（个别线程长期等待锁，但始终无法获取）情况发生的一个办法。

如果使用synchronized，我们根本无法进行公平性的选择，其永远是不公平的，这也是主流操作系统线程调度的选择。通用场景中，公平性未必有想象中的那么重要，Java默认的调度策略很少会导致 “饥饿”发生。与此同时，若要保证公平性则会引入额外开销，自然会导致一定的吞吐量下降。所以，我建议只有当你的程序确实有公平性需要的时候，才有必要指定它。

我们再从日常编码的角度学习下再入锁。为保证锁释放，每一个lock()动作，我建议都立即对应一个try-catch-fnally，典型的代码结构如下，这是个良好的习惯。

ReentrantLock fairLock = new ReentrantLock(true);// 这里是演示创建公平锁，一般情况不需要。
try {
	// do something
} fnally {
	fairLock.unlock();
}

ReentrantLock相比synchronized，因为可以像普通对象一样使用，所以可以利用其提供的各种便利方法，进行精细的同步操作，甚至是实现synchronized难以表达的用例，如：

• 带超时的获取锁尝试。

• 可以判断是否有线程，或者某个特定线程，在排队等待获取锁。

• 可以响应中断请求。
• …

这里我特别想强调条件变量（java.util.concurrent.Condition），如果说ReentrantLock是synchronized的替代选择，Condition则是将wait、notify、notifyAll等操作转化为相应的对象，将复杂而晦涩的同步操作转变为直观可控的对象行为。

todo 再看看这

条件变量最为典型的应用场景就是标准类库中的ArrayBlockingQueue等。

我们参考下面的源码，首先，通过再入锁获取条件变量：

/** Condition for waiting takes */
private fnal Condition notEmpty;
/** Condition for waiting puts */
private fnal Condition notFull;

public ArrayBlockingQueue(int capacity, boolean fair) {
	if (capacity <= 0)
		throw new IllegalArgumentException();
  
	this.items = new Object[capacity];
	lock = new ReentrantLock(fair);
	notEmpty = lock.newCondition();
	notFull = lock.newCondition();
}

两个条件变量是从同一再入锁创建出来，然后使用在特定操作中，如下面的take方法，判断和等待条件满足：

public E take() throws InterruptedException {
	fnal ReentrantLock lock = this.lock;
	lock.lockInterruptibly();
	try {
		while (count == 0)
		notEmpty.await();
		return dequeue();
	} fnally {
		lock.unlock();
	}
}

当队列为空时，试图take的线程的正确行为应该是等待入队发生，而不是直接返回，这是BlockingQueue的语义，使用条件notEmpty就可以优雅地实现这一逻辑。

那么，怎么保证入队触发后续take操作呢？请看enqueue实现：

private void enqueue(E e) {
// assert lock.isHeldByCurrentThread();
// assert lock.getHoldCount() == 1;
// assert items[putIndex] == null;
fnal Object[] items = this.items;
items[putIndex] = e;
if (++putIndex == items.length) putIndex = 0;
	count++;
	notEmpty.signal(); // 通知等待的线程，非空条件已经满足
}

通过signal/await的组合，完成了条件判断和通知等待线程，非常顺畅就完成了状态流转。注意，signal和await成对调用非常重要，不然假设只有await动作，线程会一直等待直到被打断（interrupt）。

从性能角度，synchronized早期的实现比较低效，对比ReentrantLock，大多数场景性能都相差较大。但是在Java 6中对其进行了非常多的改进，可以参考性能对比，在高竞争情况下，ReentrantLock仍然有一定优势。我在下一讲进行详细分析，会更有助于理解性能差异产生的内在原因。在大多数情况下，无需纠结于性能，还是考虑代码书写结构的便利性、可维护性等。

https://dzone.com/articles/synchronized-vs-lock

今天，作为专栏进入并发阶段的第一讲，我介绍了什么是线程安全，对比和分析了synchronized和ReentrantLock，并针对条件变量等方面结合案例代码进行了介绍。下一讲，我将对锁的进阶内容进行源码和案例分析。

一课一练

关于今天我们讨论的synchronized和ReentrantLock你做到心中有数了吗？思考一下，你使用过ReentrantLock中的哪些方法呢？分别解决什么问题？

TODO

公号-Java大后端

2018-06-07

ReentrantLock是Lock的实现类，是一个互斥的同步器，在多线程高竞争条件下，ReentrantLock比synchronized有更加优异的性能表现。

1 用法比较

Lock使用起来比较灵活，但是必须有释放锁的配合动作

Lock必须手动获取与释放锁，而synchronized不需要手动释放和开启锁

Lock只适用于代码块锁，而synchronized可用于修饰方法、代码块等

2 特性比较

ReentrantLock的优势体现在：

具备尝试非阻塞地获取锁的特性：当前线程尝试获取锁，如果这一时刻锁没有被其他线程获取到，则成功获取并持有锁

能被中断地获取锁的特性：与synchronized不同，获取到锁的线程能够响应中断，当获取到锁的线程被中断时，中断异常将会被抛出，同时锁会被释放

超时获取锁的特性：在指定的时间范围内获取锁；如果截止时间到了仍然无法获取锁，则返回

3 注意事项

在使用ReentrantLock类的时，一定要注意三点：

在fnally中释放锁，目的是保证在获取锁之后，最终能够被释放

不要将获取锁的过程写在try块内，因为如果在获取锁时发生了异常，异常抛出的同时，也会导致锁无故被释放。

ReentrantLock提供了一个newCondition的方法，以便用户在同一锁的情况下可以根据不同的情况执行等待或唤醒的动作。

逐梦之音

2018-06-07

一直在研究JUC方面的。所有的Lock都是基于AQS来实现了。AQS和Condition各自维护了不同的队列，在使用lock和condition的时候，其实就是两个队列的互相移动。如果我们想自定义一个

同步器，可以实现AQS。它提供了获取共享锁和互斥锁的方式，都是基于对state操作而言的。ReentranLock这个是可重入的。其实要弄明白它为啥可重入的呢，咋实现的呢。其实它内部自定

义了同步器Sync，这个又实现了AQS，同时又实现了AOS，而后者就提供了一种互斥锁持有的方式。其实就是每次获取锁的时候，看下当前维护的那个线程和当前请求的线程是否一样，一样就

可重入了。

作者回复

2018-06-08

正解

Kyle

2018-06-07

最近刚看完《Java 并发编程实战》，所以今天看这篇文章觉得丝毫不费力气。开始觉得，极客时间上老师讲的内容毕竟篇幅有限，更多的还是需要我们课后去深入钻研。希望老师以后讲完课也

能够适当提供些参考书目，谢谢。

作者回复

2018-06-07

后面会对实现做些源码分析，其实还有各种不同的锁…

BY

2018-06-07

极客时间

要是早看到这篇文章，我上次面试就过了。。

作者回复

2018-06-08

加油

灰飞灰猪不会灰飞.烟灭

2018-06-07

ReentrantLock 加锁的时候通过cas算法，将线程对象放到一个双向链表中，然后每次取出链表中的头节点，看这个节点是否和当前线程相等。是否相等比较的是线程的ID。

老师我理解的对不对啊？

作者回复

2018-06-08

嗯，并发库里都是靠自己的synchronizer

木瓜芒果

2018-06-19

杨老师，您好，synchronized在低竞争场景下可能优于retrantlock，这里的什么程度算是低竞争场景呢？

作者回复

2018-06-19

这个精确的标准我还真不知道，我觉得可以这么理解：如果大部分情况，每个线程都不需要真的获取锁，就是低竞争；反之，大部分都要获取锁才能正常工作，就是高竞争

xinfangke

2018-06-08

老师 问你个问题 在spring中 如果标注一个方法的事务隔离级别为序列化 而数据库的隔离级别是默认的隔离级别 此时此方法中的更新 插入语句是如何执行的？能保证并发不出错吗

作者回复

2018-06-08

这个我没用过，哪位读者熟悉？

sunlight001

2018-06-07

老师这里说的低并发和高并发的场景，大致什么数量级的算低并发？我们做管理系统中用到锁的情况基本都算低并发吧

作者回复

2018-06-07

还真不知道有没有具体标准，但从逻辑上，低业务量不一定是“低竞争”，可能因为程序设计原因变成了“高竞争”

Daydayup

2018-06-13

我用过读写分离锁，读锁保证速度，写锁保证安全问题。再入锁还是挺好用的。老师写的很棒，学到不少知识。感谢

作者回复

2018-06-13

非常感谢

Daydayup

2018-06-13

我用过读写分离锁，读锁保证速度，写锁保证安全问题。再入锁还是挺好用的。老师写的很棒，学到不少知识。感谢

李飞

2018-06-08

老师，可以问您一个课外题吗。具备怎样的能力才算是java高级开发

Libra

2018-06-07

希望后面能讲下lock源码整个的设计思想。

wang_bo

2018-06-07

该怎么系统学习java并发？

Allen

2018-07-08

为什么ReentranLock会如此高效？

张小小的席大da

2018-07-02

杨老师 很感谢 在您这了解到了很多以前没注意的知识点 时刻关注着您 希望您会一直讲下去

猪哥灰

2018-06-29

为了研究java的并发，我先把考研时候的操作系统教材拿出来再仔细研读一下，可见基础之重要性，而不管是什么语言，万变不离其宗

飞鱼

2018-06-17

之前有被问到synchronize和ReetrantLock底层实现上的区别，笼统的答了下前者是基于JVM实现的，后者依赖于CPU底层指令的实现，关于这个，请问有更详细的解答吗？

作者回复

2018-06-19

synchronized已经介绍了，后面我会介绍AQS，reentrantlock等多种同步结构都是利用它实现的；其实你说的靠计算机之类也对，我想你的意思是cas的实现？

云学

2018-06-15

锁是针对数据的，不是针对代码，一个数据一把锁，syncrise似乎违背了这一原则

云学

2018-06-14

看完还是觉得c++11的Lockguard比较优雅，难怪耗子哥说学习java是为了更好的用c++

作者回复

2018-06-14

互相影响，底层也有很多一致的地方，类似jmm之类也是c++掉的坑，别人吸取了教训

Miaozhe

2018-06-12

杨老师，问个问题，看网上有说Condition的await和signal方法，等同于Object的wait和notify，看了一下源码，没有直接的关系。

极客时间

ReentractLock是基于双向链表的对接和CAS实现的，感觉比Object增加了很多逻辑，怎么会比Synchronized效率高？有疑惑。

作者回复

2018-06-12

你看到的很对，如果从单个线程做的事来看，也许并没有优势，不管是空间还是时间，但ReentrantLock这种所谓cas，或者叫lock-free，方式的好处，在于高竞争情况的扩展性，而原来那

种频繁的上下文切换则会导致吞吐量迅速下降

Miaozhe

2018-06-12

Reentrant Lock的示例的代码好像不完整。

liyaocai

2018-06-08

老师，最近在看并发包的源码，发现8与9的源码改了不少，应该以哪个版本为重呢

liyaocai

2018-06-08

在阅读代码时发现 ReentrantLock中nonfairTryAcquire 中 对state做了溢出判断，我想问一下，除了死循环，还有什么情况会导致溢出呢？

if (current == getExclusiveOwnerThread()) {

int nextc = c + acquires;

if (nextc < 0) // overfow

throw new Error(“Maximum lock count exceeded”);

setState(nextc);

return true;

}

徐金铎

2018-06-08

补充一点，Syc的静态方法和syc(.class)确实是一样的，但是前者是在方法前加syc的fag，后者在反编译后的代码中看不到。所以我查阅了hotspot的文档和代码，确定这一个细节处理是

有jvm做的。两者实际运行，确实是一样的处理。

作者回复

2018-06-10

对，字节码不一样，但语义是一样

java爱好者

2018-06-08

老师，怎么判断一个队列是有界或无界，arrayblockingqueue是有界

作者回复

2018-06-08

这个每个queue的javadoc都明确说明了，有什么疑问？

雷霹雳的爸爸

2018-06-08

真不记得自己用过，诚如老师所讲，其有特殊语义能力，如超时，公平性等，但窃以为别给自己添乱最好，万一忘了unlock，话说他这玩意儿为啥不设计个类似try…with…resource的语法糖？

估计就是为了把加锁解锁的语法能力分散在不同子例程里撰写使用的考虑？可问题是如果都写成那样了，是否有说明自己程序设计上内聚性不够呢？嗯，再看点源码来找答案吧…话说JCIP真是

好书，学不学究的读读资本论之后就释然了，如果真能顺着它仔细读下来，发现它针对特定栗子还会随着内容深入给出不同解法，不禁感叹，也许在利用较低级别的通信原语时，很有可能是对

并发包里面一些现成工具类缺乏了解或者是对真正的并发问题缺乏深入理解造成的…虽然自己看起来也就是个CRUD开发的老佃户命了，还是非常期待老师后面的主题，毕竟咱还是有颗通向地主

阶层的心

作者回复

2018-06-08

有些场景，就类似blockingQueue，用sync表达要吃力些，甚至有时候是表达不出来的

一个帅哥

2018-06-08

从书写角度：reentrantlock 需要手动获取和释放锁，而syncgeonised不需要手动获取和释放

所以，此外，reentrantlock有trylock 和lockinterruptly ，所以对锁的操作更灵活。从功能的角度看，reentrantlock支持公平锁和非公平锁 而synchronized 仅支持非公平锁。

kai

2018-06-07

在大部分并发编程资料都是将ReentrantLock翻译为”重入锁”。

谢

2018-06-07

ReentranLock相比Synchronized，可以实现更多的锁细节。

超时的锁获取

可以判断是否有线程在等待锁

可以响应中断请求

灰飞灰猪不会灰飞.烟灭

2018-06-07

老师，signal和await和notify wait有啥区别呢？

还有lock方式放入双向链表中的node，是不是按照线程对象（对象地址）进行比较的啊？

就是如何判断当前线程是否获得锁是不是按照线程对象地址啊。谢谢老师

作者回复

2018-06-07

有点类似；使用并发库，大部分情况下不再需要调用Object的nitify wait之类，简化了很多；

后面的问题我没太看明白

极客时间

极客时间

周末福利	谈谈我对Java学习和面试的看法

2018-06-09 杨晓峰

周末福利	谈谈我对Java学习和面试的看法

杨晓峰

- 00:21 / 07:18

你好，我是杨晓峰。今天是周末，我们稍微放松一下来聊聊“Java核心技术”之外的内容，正好也借这个机会，兑现一下送出学习奖励礼券的承诺。我在每一讲后面都留下了一道思考

题，希望你通过学习，结合自身工作实际，能够认真思考一下这些问题，一方面起到检验学习效果的作用，另一方面可以查漏补缺，思考一下这些平时容易被忽略的面试考察点。我

并没有给出这些思考题的答案，希望你通过专栏学习或者查阅其他资料进行独立思考，将自己思考的答案写在留言区与我和其他同学一起交流，这也是提升自己重要的方法之一。

截止到今天，专栏已经更新了15讲，走完了基础模块正式进入进阶模块。现在也正是一个很好的时机停下来回顾一下基础部分的知识，为后面进阶的并发内容打好基础。在这里，我

也分享一下我对Java学习和面试的看法，希望对你有所帮助。

首先，有同学反馈说专栏有的内容看不懂。我在准备专栏文章的时候对一些同学的基础把握不太准确，后面的文章我进行了调整，将重点技术概念进行讲解，并为其他术语添加链

接。

再来说说这种情况，有人总觉得Java基础知识都已经被讲烂了，还有什么可学的？

对于基础知识的掌握，有的同学经常是“知其然而不知其所以然”， 看到几个名词听说过就以为自己掌握了，其实不然。至少，我认为应该能够做到将自己“掌握”的东西，准确地表达

出来。

爱因斯坦曾经说过，“如果你不能把它简单地解释出来，那说明你还没有很好地理解它”。了解-掌握-精通，这是我们对事物掌握的一个循序渐进的过程。从自己觉得似乎懂了，到能

够说明白，再到能够自然地运用它，甚至触类旁通，这是不断提高的过程。

在专栏学习中，如果有些术语很陌生，那么了解它就达到了学习目的，如果能够理解透彻达到掌握的程度当然更好。乐观点来看，反正都是有收获，也完全不必过分担心。

从学习技巧的角度，每个人都有自己的习惯，我个人喜欢动手实践以及与人进行交流。

动手实践是必要一步，如果连上手操作都不肯，你会发现自己的理解很难有深度。

在交流的过程中你会发现，很多似是而非的理解，竟然在试图组织语言的时候，突然就想明白了，而且别人的观点也验证了自己的判断。技术领域尤其如此，把自己的理解整理成

文字，输出、交流是个非常好的提高方法，甚至我认为这是技术工作者成长的必经之路。

再来聊聊针对技术底层，我们是否有必要去阅读源代码？

阅读源代码当然是个好习惯，理解高质量的代码，对于提高我们自己的分析、设计等能力至关重要。

根据实践统计，工程师实际工作中，阅读代码的时间其实大大超过写代码的时间，这意味着阅读、总结能力，会直接影响我们的工作效率！这东西有没有捷径呢，也许吧，我的心

得是：“无他，但手熟尔”。

参考别人的架构、实现，分析其历史上掉过的坑，这是天然的好材料，具体阅读时可以从其修正过的问题等角度入手。

现代软件工程，节奏越来越快，需求复杂而多变，越来越凸显出白盒方式的重要性。快速定位问题往往需要黑盒结合白盒能力，对内部一无所知，可能就没有思路。与此同时，通

用平台、开源框架，不见得能够非常符合自己的业务需求，往往只有深入源代码层面进行定制或者自研，才能实现。我认为这也是软件工程师地位不断提高的原因之一。

那么，源代码需要理解到什么程度呢？ 对于底层技术，这个确实是比较有争议的问题，我个人并不觉得什么东西都要理解底层，懂当然好，但不能代表一切，毕竟知识和能力是有区

别的，当然我们也要尊重面试官的要求。我个人认为，不是所有做Java开发的人，都需要读JVM源代码，虽然我在专栏中提供了一些底层源代码解读，但也只是希望真的有兴趣、有

需要的工程师跟进学习。对于大多数开发人员，了解一些源代码，至少不会在面试问到的时候完全没有准备。

关于阅读源代码和理解底层，我有些建议：

带着问题和明确目的去阅读，比如，以debug某个问题的角度，结合实践去验证，让自己能够感到收获，既加深理解，也有实际帮助，激励我们坚持下来。

一定要有输出，至少要写下来，整理心得，交流、验证、提高。这和我们日常工作是类似的，千万不要做了好长一段时间后和领导说，没什么结论。

大家大都是工程师，不是科学家，软件开发中需要分清表象、行为（behavior），还是约定（specifcation）。喜欢源代码、底层是好的，但是一定要区分其到底是实现细节，还是

规范的承诺，因为如果我们的程序依赖于表现，很有可能带来未来维护的问题。

我前面提到了白盒方式的重要性，但是，需要慎重决定对内部的依赖，分清是Hack还是Solution。出来混，总是要还的！如果以某种hack方式解决问题，临时性的当然可以，长久

会积累并成为升级的障碍，甚至堆积起来愈演愈烈。比如说，我在实验Cassandra的时候，发现它在并发部分引用了Unsafe.monitorEnter()/moniterExit()，这会导致它无法平

滑运行在新版的JDK上，因为相应内部API被移除了，比较幸运的是这个东西有公共API可以替代。

最后谈谈我在面试时会看中候选人的哪些素质和能力。

结合我在实际工作中的切身体会，面试时有几个方面我会特别在乎：

技术素养好，能够进行深度思考，而不是跳脱地夸夸其谈，所以我喜欢问人家最擅长的东西，如果在最擅长的领域尚且不能仔细思考，怎么能保证在下一份工作中踏实研究呢。当然

这种思考，并不是说非要死扣底层和细节，能够看出业务中平凡事情背后的工程意义，同样是不错的。毕竟，除了特别的岗位，大多数任务，如果有良好的技术素养和工作热情，

再配合一定经验，基本也就能够保证胜任了。

职业精神，是否表现出认真对待每一个任务。我们是职场打拼的专业人士，不是幼儿园被呵护的小朋友，如果有人太挑活儿，团队往往就无法做到基本的公平。有经验的管理角色，

大多是把自己的管理精力用在团队的正面建设，而不是把精力浪费在拖团队后腿的人身上，难以协作的人，没有人会喜欢。有人说你的职业高度取决于你“填坑”的能力，我觉得很

有道理。现实工作中很少有理想化的完美任务，既目标清晰又有挑战，恰好还是我擅长，这种任务不多见。能够主动地从不清晰中找出清晰，切实地解决问题，是非常重要的能

力。

是否hands-on，是否主动。我一般不要求当前需要的方面一定是很hands-on，但至少要表现出能够做到。

下面放出中奖名单和精选留言，送出15元学习奖励礼券，希望我的《Java核心技术36讲》不仅能带你走进大厂Java面试场景，还能帮你温故知新基础知识，构建你的Java知识体

系。也欢迎你在这里与我交流面试、学习方面的困惑或心得，一起畅所欲言、共同进步。

祝贺石头狮子、Woj、kursk.ye、Miaozhe、肖一林、曹铮、雷霹雳的爸爸、vash_ace、Walter，也要感谢I am a psycho、magict4、李林、Woong、L.B.Q.Y指出我文稿中

的疏漏，一并送出学习奖励礼券。

whhbbq

2018-06-09

老师的招人标准，学习了，很实用，看了也很有感触。你能填上别人填不上的坑，就成功了。工作中大多数时候的任务目标并不清晰，特别当你是一个团队的小leader时，没人告诉你后面的方

向，要做成什么样，很考验能力。

vash_ace

2018-06-11

感谢杨老师的鼓励，在受宠若惊之余，我觉得这篇“课外阅读”的参考价值不输于任何一篇技术分享。因为文中提到的这些努力或坚持的方向，确实是对个人职场生涯有着巨大的影响和帮助(亲测

有效)。

其实道理大家都懂，但很多时候想当架构相做技术大牛的我们就是会以各种理由(项目忙，赶进度，不想加班…)不去对一个bug或一次线上故障做刨根问底的努力，又或者是放弃原本是对的坚

持(比如，技术笔记，技术阅读与分享…)；

那这个时候的你所需要的鸡汤或兴奋剂不再是XXX的成功，而是想象一下自己的个人价值。往大了说，你对技术圈做了什么贡献？影响了多少人？影响越大成就感越满足。成就感是个好东西，

你越享受就越会上瘾；往俗了说，就是看看自己的收入在行业内处于什么样的水平？工资多少不一定能完全体现一个人的真实水平，但至少绝大部分公司和猎头都能根据你上一家公司的收入来

定位你属于哪一个level。

公号-Java大后端

2018-06-09

阅读源码的时候，

首先，可通过各种公开的渠道（google、公开文档等）了解代码的总体框架、模块组成及其模块间的关系；

然后，结合源码的注释进行解读，对不是很明白的部分打断点，调试，甚至可按照自己的想法进行修改后再调试；

最后，对于重点核心模块进行详细调试，可以把核心类的功能、调用流程等写下来，好记性总是敌不过烂笔头的。

除此之外，个人觉得最最重要的是:看源码的时候要有”静气”。

夏洛克的救赎

2018-06-09

看评论都能涨知识，希望评论提供交互功能

雷霹雳的爸爸

2018-06-09

意外，感谢，更重要的是也复盘下这段学习过程中发现的自己的各种不足，再接再厉！

iLeGeND

2018-06-09

我们应该面向接口编程，面向规范编程，在单纯的开发中，使jdk或者框架，应该以其api文档为参考，如果有问题就看源码，那岂不是面子实现编程了，不同的版本，其实现不见得一样，我们

的代码用不能一直改吧

Hidden

2018-06-13

我在阅读源码的时候，只能勉强理解一半，剩下那一半 再怎么也理解不了，很是奇怪，

Zoe.Li

2018-06-12

谢谢杨老师的分享

Miaozhe

2018-06-11

感谢杨老师分享，这次学习收获很大，特别是认真阅读了HashMap的源码，桶的设计和Hash的位运算正的设计很妙。以前没有看懂，这次参考老师的”死磕”，终于看懂了。

LenX

2018-06-10

正文中(非留言区)，倒数第二个推荐的读者留言中说:

“所以一般建议在使用 Netty 时开启 XX:+DisableExplicitGC”。

注意，参数前使用的是 + 号，我觉得不对吧！

这就表明 Ststem.gc 变成空调用了，这对于 Netty，如果这么做会导致堆外内存不及时回收，反而更容易 OOM。

是这样吗？

作者回复

2018-06-10

我认为看场景和侧重角度，如果发现cleaner自动回收不符合需求，用system.gc至少可以避免oom；如果应用没这问题，调用它也可能导致应用反应不稳定等问题。

所以没有一劳永逸的办法或者最佳实践，只能是个思路参考，看实际需求

肖一林

极客时间

2018-06-09

谢谢老师的奖励，每一篇都在看，最近也在组织以前的笔记，放在自己的技术公众号。希望清理技术债务，达到系统学习的目的。结合以前所学，加上老师文章提到的一些底层原理，用自己的

方式表达一遍

作者回复

2018-06-10

加油，互相提高

zt

2018-06-09

话说今天不更新了吗，大神能不能加快下更新的速度，学习完去面试，战线时间太长有点熬人

作者回复

2018-06-10

有规定的节奏

iLeGeND

2018-06-09

我们应该面向接口编程，面向规范编程，在单纯的开发中，使jdk或者框架，应该以其api文档为参考，如果有问题就看源码，那岂不是面子实现编程了，不同的版本，其实现不见得一样，我们

的代码用不能一直改吧