当实例方法被synchronized修饰时，通过当前实例调用此方法的所有线程共用一把锁，不同对象调用此方法线程间互不影响。
当使用synchronized锁修饰实例方法，锁添加在当前类的实例上，有多少个实例可添加多少把锁。
修饰代码块比修饰方法颗粒度更小。当实例方法代码块被synchronized修饰时，通过当前实例调用此方法的所有线程共用一把锁，不同对象调用此方法线程间互不影响。
当使用synchronized锁修饰代码块，锁添加在当前类的实例上，有多少个实例可添加多少把锁。
当静态方法被synchronized修饰时，整个JVM所有调用此方法的线程均受同一个锁的约束。
当使用synchronized锁修饰静态方法，锁添加在当前类的类对象上，最多添加一把锁。
Java 8所使用的synchronized锁是经过优化后的，存在偏向锁、轻量级锁、重量级锁等状态。
线程间不存在锁的竞争行为，至多只有一个线程有获取锁的需求，常见场景为单线程程序。
判断是不是偏向锁的标识是查看调用此方法的线程是否有且仅有一个。
在多线程编程里，被锁修饰的方法仅被单一线程调用几乎不存在，因此偏向锁比较鸡肋：如果能够明确单一线程调用目标方法，使用无锁编程更为合适。
无锁与偏向锁的性能差异非常接近，几乎可以忽略不计。
线程间存在锁的伪竞争行为，即同一时刻绝对不会存在两个线程申请获取锁，各线程尽管都有使用锁的需求，但是是交替使用锁。
当有两个及以上线程调用被锁修饰的方法时，那么至少能确定是轻量级锁。
轻量级锁由于同一时刻不存在两个线程互相竞争锁，因此不存在线程阻塞-唤醒的上下文切换，因此性能相对重量级锁要高很多。
线程间存在锁的实质性竞争行为，线程间都有获取锁的需求，但是时间不可交错，互斥锁的阻塞等待。
当能够肯定至少有两个及以上线程调用被锁修饰的方法时，线程调用方法是随机的，那么大概率是重量级锁。
重量级锁由于涉及到线程阻塞-唤醒的上下文切换，造成相比较与无锁状态，效率低很多。
synchronized锁是非公平锁，没有FIFO队列机制保障竞争锁的线程一定有几率获得锁。
synchronized锁是可重入锁，可重入意味着嵌套调用不会产生死锁问题。
synchronized锁是一种悲观锁，通过加锁实现线程间同步。
在多线程环境下，如果使用synchronized锁，那么大概率会升级到重量级锁。偏向锁和轻量级锁非刻意为之，很难存在，更大的意义是对比帮助理解重量级锁的性能。
重量级锁尽管会对性能产生很大影响，但是依旧是解决线程间同步的有效手段。
当被锁修饰的方法或者代码块执行时间较长时，选用基于线程阻塞-唤醒切换上下文的方式进行线程同步效率相对较高。
当被锁修饰的方法或者代码块执行时间较短时，应选用其它替代锁，比如自旋锁等。
在实际多线程场景开发中，synchronized锁大概率会升级到重量级锁，因其单向升级的特点，重量级状态的synchronized锁可能会对实际业务的并发产生不利影响，手动选用其它锁可能会更合适。
synchronized锁仅可用于解决同一进程内不同线程间同步，对于分布式项目跨进城线程同步依赖于分布式锁，synchronized锁更多的意义是理解锁的过程。
Java中的锁主要包括synchronized锁和JUC包中的锁，这些锁都是针对单个JVM实例上的锁，对于分布式环境如果我们需要加锁就显得无能为力。在单个JVM实例上，锁的竞争者通常是一些不同的线程，而在分布式环境中，锁的竞争者通常是一些不同的线程或者进程。如何实现在分布式环境中对一个对象进行加锁呢？答案就是分布式锁。
目前分布式锁的实现方案主要包括三种：
基于数据库实现分布式锁主要是利用数据库的唯一索引来实现，唯一索引天然具有排他性，这刚好符合我们对锁的要求：同一时刻只能允许一个竞争者获取锁。加锁时我们在数据库中插入一条锁记录，利用业务id进行防重。当第一个竞争者加锁成功后，第二个竞争者再来加锁就会抛出唯一索引冲突，如果抛出这个异常，我们就判定当前竞争者加锁失败。防重业务id需要我们自己来定义，例如我们的锁对象是一个方法，则我们的业务防重id就是这个方法的名字，如果锁定的对象是一个类，则业务防重id就是这个类名。
基于缓存实现分布式锁：理论上来说使用缓存来实现分布式锁的效率最高，加锁速度最快，因为Redis几乎都是纯内存 *** 作，而基于数据库的方案和基于Zookeeper的方案都会涉及到磁盘文件IO，效率相对低下。一般使用Redis来实现分布式锁都是利用Redis的 SETNX key value 这个命令，只有当key不存在时才会执行成功，如果key已经存在则命令执行失败。
基于Zookeeper：Zookeeper一般用作配置中心，其实现分布式锁的原理和Redis类似，我们在Zookeeper中创建瞬时节点，利用节点不能重复创建的特性来保证排他性。
在实现分布式锁的时候我们需要考虑一些问题，例如：分布式锁是否可重入，分布式锁的释放时机，分布式锁服务端是否有单点问题等。
上面已经分析了基于数据库实现分布式锁的基本原理：通过唯一索引保持排他性，加锁时插入一条记录，解锁是删除这条记录。下面我们就简要实现一下基于数据库的分布式锁。
id字段是数据库的自增id，unique_mutex字段就是我们的防重id，也就是加锁的对象，此对象唯一。在这张表上我们加了一个唯一索引，保证unique_mutex唯一性。holder_id代表竞争到锁的持有者id。
如果当前sql执行成功代表加锁成功，如果抛出唯一索引异常(DuplicatedKeyException)则代表加锁失败，当前锁已经被其他竞争者获取。
解锁很简单，直接删除此条记录即可。
是否可重入 ：就以上的方案来说，我们实现的分布式锁是不可重入的，即是是同一个竞争者，在获取锁后未释放锁之前再来加锁，一样会加锁失败，因此是不可重入的。解决不可重入问题也很简单：加锁时判断记录中是否存在unique_mutex的记录，如果存在且holder_id和当前竞争者id相同，则加锁成功。这样就可以解决不可重入问题。
锁释放时机 ：设想如果一个竞争者获取锁时候，进程挂了，此时distributed_lock表中的这条记录就会一直存在，其他竞争者无法加锁。为了解决这个问题，每次加锁之前我们先判断已经存在的记录的创建时间和当前系统时间之间的差是否已经超过超时时间，如果已经超过则先删除这条记录，再插入新的记录。另外在解锁时，必须是锁的持有者来解锁，其他竞争者无法解锁。这点可以通过holder_id字段来判定。
数据库单点问题 ：单个数据库容易产生单点问题：如果数据库挂了，我们的锁服务就挂了。对于这个问题，可以考虑实现数据库的高可用方案，例如MySQL的MHA高可用解决方案。
使用Jedis来和Redis通信。
可以看到，我们加锁就一行代码：
jedis.set(String key, String value, String nxxx, String expx, int time)
这个set()方法一共五个形参：
第一个为key,我们使用key来当锁，因为key是唯一的。
第二个为value，这里写的是锁竞争者的id，在解锁时，我们需要判断当前解锁的竞争者id是否为锁持有者。
第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set *** 作；若key已经存在，则不做任何 *** 作。
第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期时间的设置，具体时间由第五个参数决定；
第五个参数为time，与第四个参数相呼应，代表key的过期时间。
总的来说，执行上面的set()方法就只会导致两种结果：1.当前没有锁（key不存在）,那么久进行加锁 *** 作，并对锁设置一个有效期，同时value表示加锁的客户端。2.已经有锁存在，不做任何 *** 作。
上述解锁请求中， SET_IF_NOT_EXIST (不存在则执行)保证了加锁请求的排他性，缓存超时机制保证了即使一个竞争者加锁之后挂了，也不会产生死锁问题：超时之后其他竞争者依然可以获取锁。通过设置value为竞争者的id，保证了只有锁的持有者才能来解锁，否则任何竞争者都能解锁，那岂不是乱套了。
解锁的步骤：
注意到这里解锁其实是分为2个步骤，涉及到解锁 *** 作的一个原子性 *** 作问题。这也是为什么我们解锁的时候用Lua脚本来实现，因为Lua脚本可以保证 *** 作的原子性。那么这里为什么需要保证这两个步骤的 *** 作是原子 *** 作呢？
设想：假设当前锁的持有者是竞争者1，竞争者1来解锁，成功执行第1步，判断自己就是锁持有者，这是还未执行第2步。这是锁过期了，然后竞争者2对这个key进行了加锁。加锁完成后，竞争者1又来执行第2步，此时错误产生了：竞争者1解锁了不属于自己持有的锁。可能会有人问为什么竞争者1执行完第1步之后突然停止了呢？这个问题其实很好回答，例如竞争者1所在的JVM发生了GC停顿，导致竞争者1的线程停顿。这样的情况发生的概率很低，但是请记住即使只有万分之一的概率，在线上环境中完全可能发生。因此必须保证这两个步骤的 *** 作是原子 *** 作。
是否可重入 ：以上实现的锁是不可重入的，如果需要实现可重入，在 SET_IF_NOT_EXIST 之后，再判断key对应的value是否为当前竞争者id，如果是返回加锁成功，否则失败。
锁释放时机 ：加锁时我们设置了key的超时，当超时后，如果还未解锁，则自动删除key达到解锁的目的。如果一个竞争者获取锁之后挂了，我们的锁服务最多也就在超时时间的这段时间之内不可用。
Redis单点问题 ：如果需要保证锁服务的高可用，可以对Redis做高可用方案：Redis集群+主从切换。目前都有比较成熟的解决方案。
利用Zookeeper创建临时有序节点来实现分布式锁：
其基本思想类似于AQS中的等待队列，将请求排队处理。其流程图如下：
解决不可重入 ：客户端加锁时将主机和线程信息写入锁中，下一次再来加锁时直接和序列最小的节点对比，如果相同，则加锁成功，锁重入。
锁释放时机 ：由于我们创建的节点是顺序临时节点，当客户端获取锁成功之后突然session会话断开，ZK会自动删除这个临时节点。
单点问题 ：ZK是集群部署的，主要一半以上的机器存活，就可以保证服务可用性。
Zookeeper第三方客户端curator中已经实现了基于Zookeeper的分布式锁。利用curator加锁和解锁的代码如下：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）