声明本文章只是对锁理解的个人理解点。
背景
在编程的世界锁是在处理高并发多线程可以说必须用到的机制或者说手段。首先要清楚的了解知道为什么要用锁？在面试过程中或者在实际开发过程中都在说线程安全 并发安全这些安全到底是指的什么？
核心秘诀-锁的共性（重点）
**在实际开发过程中锁核心要点就是锁的共性问题。找到了锁的标识就可以更好的去理解这个技术点核心。带着三个疑问去看看syn、lock、redis、zk是怎么设计的。
- 锁标识是什么
- 操作锁的原子操作
- 谁拥有锁**
为了解决什么问题？
其实线程安全也好，还是并发安全。都是为了解决我们的数据安全。就是在多线程处理的时候，数据值能按照程序设计的去执行的这么一个过程。设定这么一个场景，厕所坑位门锁。当占用这个坑位的时候，就只能一个人使用。怎么确定这个坑位是否有人？就得需要一个标识让其他人感知到。这个标识就是锁标识。
锁的原理
在编程上同样也是如此。syn关键字、JUC下面的aqs框架、redis分布式锁、zk分布式锁、在这些锁上你都能找到锁标识的这个影子。syn 是mark word 对象中的锁标志位、aqs队列同步器独享锁、共享锁的 state值、redis 分布式锁的 setnx命令设置的key标识。zk分布式锁的node临时对象。
只讲述锁的通用设计原理，详细细节需要看一下代码
synchronized
syn锁的标识存在对象头的Mark Word中。举例说一下(锁的标识符为了好理解自己定义的)
- 1、 当线程1请求获取锁的时候发现没有设置锁，线程1 拿到锁，锁的标识从0 变成1 设置owenr(为了知道谁进去占了厕所的坑位)为当前线程ID。
- 2 、当线程1再次请求获取锁的时候发现偏向锁再次获取锁。发现是偏量锁，对比owenr的id发现是同一个线程直接不进行锁操作。这里就是锁的重入性。
- 3、当线程1 还没有执行完毕。线程2尝试获取锁。发现已经上锁了，不是自己上的锁。那就只能在门口等待。锁就开始变成轻量级锁。
- 4、当线程3又来的时候发现这个坑位还是线程1占有。发现线程2也在等待呢。这个时候锁的状态就变成重量级锁。因为2和3开始煎熬的等待了。2之前是在等待，1用完马上就轮到自己了，发现3来了以后这回完喽。2和3要等1用完之后抢坑位。本来就憋着呢，又来一个抢占坑位的。
这个是syn底层锁的一个流程。当然里面还有更加详细的解释介绍。但是这里不做解释。
共性
- 锁标识是 makr word
- 操作锁的原子操作
- 谁加的锁 owenr
JUC下的AQS
在JUC下面的主要使用的是AQS，真正底层锁的实现使用的是CAS锁 对比、交换。这个是jvm底层提供的unsafe类的compareAndSwapInt方法设置的state值
AQS框架其实提供了一个state标识。在利用CAS原子操作进行独占锁和共享锁。
* 独占锁 线程修改AQS的state值，标记为独占锁
* 共享锁 共享锁其实是使用了队列去完成了整个操作。
* 主要应用 信号量 栅栏锁、等其他的地方
共性
- 锁标识是AQS 的state值
- 操作锁的原子 CAS
- 谁加的锁 当前线程
zk的分布式锁
使用zookeeper创建临时序列节点来实现分布式锁，适用于顺序执行的程序，大体思路就是创建临时序列节点，找出最小的序列节点，获取分布式锁，程序执行完成之后此序列节点消失，通过watch来监控节点的变化，从剩下的节点的找到最小的序列节点，获取分布式锁，执行相应处理，依次完成
解法二
zk节点唯一的！ 不能重复！节点类型为临时节点，线程1创建成功，线程2和线程3创建节点时候会报错，该节点已经存在。这时候线程2和线程3等待。线程1的程序现在执行完毕，执行释放锁。关闭当前会话。临时节点不复存在了并且事件通知Watcher，线程2和线程3继续创建。
共性
- 锁标识是节点(path)
- 操作锁的原子 zk的机制
- 谁加的锁 服务器节点
redis的分布式锁
redis的分布式锁的实现 zk的解法二 原理是一样的。设置一个标识(redis:key)
* 设置标识
* 成功
* 获取到锁并设置过期时间
* 自动或超时释放
* 失败
* 自旋等待直到成功创建标识
共性
- 锁标识是 Redis key标识
- 操作锁的原子 redis单线程原子操作
- 谁加的锁 连接redis的操作线程
总结
其实不难发现，锁的核心理解就是在设置锁标识的一个过程。在学习理解锁的过程就是找到共性的东西。就本篇文章而言就是找到了锁的共性三点：
- 锁标识
- 原子性
- 谁持有锁
希望大家能有自己总结实践。毕竟学习要持续性的过程。以上是个人浅显的总结。
