在技术论坛中，经常看到一种言论：面试造火箭，干活拧螺丝。我们平时写的大部分代码的确是CRDU，再提一个层次，也无非就是揉进去复杂一些的业务逻辑，把一堆的CRDU组合起来。
那么问题来了：我们提倡的研究“底层技术”，难道仅仅是为了面试？或是为了平时码农们聊天时装大佬吗？
当然不是！
小端随着工作年限的增加，深有感悟：
技术是我们程序员的工具箱。
CRDU是我们的默认工具。
平时的点滴积累就是在不断的丰富自己的工具箱，增加工具种类。
而深挖技术细节，就是在更深入的掌握每一个工具的特性。
在工作中遇到问题时，如果一直使用默认工具，那么随着问题域的越来越大，总会遇到捉襟见肘的尴尬。
如果工具箱中不断的加入得心应手的工具，嗯，办法就会总比问题多。
以下面即将讲的synchronized锁为例子，如果对它没有清晰的了解，那么在解决线程安全性问题时，第一反应是尽量避免使用；如果实在避免不掉而用之，也是简单的模仿，这样自己其实心里也是没底的，也不清楚带来的开销有多大影响，甚至不清楚是否能真正解决问题，只能期盼上线后，一切平安...
小端会写一个系列，以面试中的问题作为切入点（毕竟这种问题涉及到的，是大部分技术人员比较关注，平时也经常使用到的技术），深入技术底层进行分析，搭建自己的知识体系。期望对看到这篇文章的您，有所启发。
好，下面进入正题。
如果有人让你讲讲synchronized的实现细节，那么，
面试官：synchronized关键字用过吗？讲讲你对他的了解...
有没有一种被他虐我千百遍的感觉？这个知识点也算是面试中的必现题型了。
不过，以小端的经验，有的面试官浅尝辄止，有的面试官则穷追猛打。前一种，可能面试官自己也不太熟悉，我们辛辛苦苦准备的东西，刚开个头，就被叫停了，不尽兴有没有；而后一种，一般会不断的深挖，一直问到我们的知识盲区。
1.在第一类面试官面前，我们需要引导，需要争取足够的时间把他的知识盲区讲清楚，借此展示出自己的知识深度。
2.在第二类面试官面前，大部分时间是知识体系对等的交流，这就需要我们做到回答时能提纲掣领，一旦深入细节有条理。
那么问题来了，如何做到呢？
小端利用十一假期，重新梳理和总结相关知识点，试图勾勒出一个5层金字塔结构（后面称为S金字塔），来帮助大家构建自有的完整知识体系。
希望在“大场面”中，你也能做到：任你风起云涌,我自岿然不动！
先放出S金字塔，一睹为快：
抛出大纲很重要
我们大多数人，更习惯于平铺直叙的方式，描述一个相对复杂的知识结构。
殊不知对于你的听众来说，其实这是一种负担。
对方要全程集中注意力，要在听后面内容的时候，不断的重复回忆前面听到的内容，只有这样，才能在听到最后时，构建出相对完整的思维模型，才能方便理解对话的真正含义。
否则就会产生压迫感，对自己不熟悉的知识更甚【上述第一种面试官】。
这是人的天性使然。
如果我们在对话的刚开始，就先抛出一个简明的大纲，先帮助对方建立起完整的模型，然后我们再针对每一个分支，做专项描述，让对方只需要边听边对照大纲印证，减少了中间记忆和回忆的环节，无疑会大大减轻对方的压力。
所以，针对这个问题，小端一般会首先告诉对方：我将从关键字的应用（初入山门）、字节码层面的细节（入室弟子）、内部组件（大师兄）、以及组件工作的流程（长老）四个方面来做解释。
PS：可能有的同学要问了，怎么少了一层，S塔尖呢？恩...正如字面，我们只是芸芸众生，这个高度需要潜心研究，还是留给大神以及有志于成为大神的同学吧。
第一层：我们看到的样子-synchronized关键字的应用
这层是基础。
在多线程编程时，synchronized经常被用来解决互斥导致的线程安全性问题。用法有两种个，一种用在方法声明中：
public synchronized void run() { //... }