让天下没有难学的技术
聊聊并发（四）深入分析ConcurrentHashMap
聊聊并发（四）深入分析ConcurrentHashMap
本文是作者原创，发表于InfoQ：
hash algorithm
是一种将任意内容的输入转换成相同长度输出的加密方式，其输出被称为哈希值。
hash table
根据设定的哈希函数H(key)和处理冲突方法将一组关键字映象到一个有限的地址区间上，并以关键字在地址区间中的象作为记录在表中的存储位置，这种表称为哈希表或散列，所得存储位置称为哈希地址或散列地址。
线程不安全的HashMap
因为多线程环境下，使用Hashmap进行put操作会引起死循环，导致CPU利用率接近100%，所以在并发情况下不能使用HashMap。
如以下代码：
final HashMap&String, String& map = new HashMap&String, String&(2);
Thread t = new Thread(new Runnable() {
public void run() {
for (int i = 0; i & 10000; i++) {
new Thread(new Runnable() {
public void run() {
map.put(UUID.randomUUID().toString(), &&);
}, &ftf& + i).start();
}, &ftf&);
t.start();
效率低下的HashTable容器
HashTable容器使用synchronized来保证线程安全，但在线程竞争激烈的情况下HashTable的效率非常低下。因为当一个线程访问HashTable的同步方法时，其他线程访问HashTable的同步方法时，可能会进入阻塞或轮询状态。如线程1使用put进行添加元素，线程2不但不能使用put方法添加元素，并且也不能使用get方法来获取元素，所以竞争越激烈效率越低。
ConcurrentHashMap的锁分段技术
HashTable容器在竞争激烈的并发环境下表现出效率低下的原因，是因为所有访问HashTable的线程都必须竞争同一把锁，那假如容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效的提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术，首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。
ConcurrentHashMap的结构
我们通过ConcurrentHashMap的类图来分析ConcurrentHashMap的结构。
ConcurrentHashMap是由Segment数组结构和HashEntry数组结构组成。Segment是一种可重入锁ReentrantLock，在ConcurrentHashMap里扮演锁的角色，HashEntry则用于存储键值对数据。一个ConcurrentHashMap里包含一个Segment数组，Segment的结构和HashMap类似，是一种数组和链表结构， 一个Segment里包含一个HashEntry数组，每个HashEntry是一个链表结构的元素， 每个Segment守护者一个HashEntry数组里的元素,当对HashEntry数组的数据进行修改时，必须首先获得它对应的Segment锁。
ConcurrentHashMap的初始化
ConcurrentHashMap初始化方法是通过initialCapacity，loadFactor, concurrencyLevel几个参数来初始化segments数组，段偏移量segmentShift，段掩码segmentMask和每个segment里的HashEntry数组。
初始化segments数组。让我们来看一下初始化segmentShift，segmentMask和segments数组的源代码。
if (concurrencyLevel & MAX_SEGMENTS)
concurrencyLevel = MAX_SEGMENTS;
// Find power-of-two sizes best matching arguments
int sshift = 0;
int ssize = 1;
while (ssize & concurrencyLevel) {
ssize &&= 1;
segmentShift = 32 -
segmentMask = ssize - 1;
this.segments = Segment.newArray(ssize);
由上面的代码可知segments数组的长度ssize通过concurrencyLevel计算得出。为了能通过按位与的哈希算法来定位segments数组的索引，必须保证segments数组的长度是2的N次方（power-of-two size），所以必须计算出一个是大于或等于concurrencyLevel的最小的2的N次方值来作为segments数组的长度。假如concurrencyLevel等于14，15或16，ssize都会等于16，即容器里锁的个数也是16。注意concurrencyLevel的最大大小是65535，意味着segments数组的长度最大为65536，对应的二进制是16位。
初始化segmentShift和segmentMask。这两个全局变量在定位segment时的哈希算法里需要使用，sshift等于ssize从1向左移位的次数，在默认情况下concurrencyLevel等于16，1需要向左移位移动4次，所以sshift等于4。segmentShift用于定位参与hash运算的位数，segmentShift等于32减sshift，所以等于28，这里之所以用32是因为ConcurrentHashMap里的hash()方法输出的最大数是32位的，后面的测试中我们可以看到这点。segmentMask是哈希运算的掩码，等于ssize减1，即15，掩码的二进制各个位的值都是1。因为ssize的最大长度是65536，所以segmentShift最大值是16，segmentMask最大值是65535，对应的二进制是16位，每个位都是1。
初始化每个Segment。输入参数initialCapacity是ConcurrentHashMap的初始化容量，loadfactor是每个segment的负载因子，在构造方法里需要通过这两个参数来初始化数组中的每个segment。
if (initialCapacity & MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
int c = initialCapacity /
if (c * ssize & initialCapacity)
int cap = 1;
while (cap & c)
cap &&= 1;
for (int i = 0; i & this.segments. ++i)
this.segments[i] = new Segment&K,V&(cap, loadFactor);
上面代码中的变量cap就是segment里HashEntry数组的长度，它等于initialCapacity除以ssize的倍数c，如果c大于1，就会取大于等于c的2的N次方值，所以cap不是1，就是2的N次方。segment的容量threshold＝(int)cap*loadFactor，默认情况下initialCapacity等于16，loadfactor等于0.75，通过运算cap等于1，threshold等于零。
定位Segment
既然ConcurrentHashMap使用分段锁Segment来保护不同段的数据，那么在插入和获取元素的时候，必须先通过哈希算法定位到Segment。可以看到ConcurrentHashMap会首先使用Wang/Jenkins hash的变种算法对元素的hashCode进行一次再哈希。
private static int hash(int h) {
h += (h && 15) ^ 0xffffcd7d; h ^= (h &&& 10);
h += (h && 3); h ^= (h &&& 6);
h += (h && 2) + (h && 14); return h ^ (h &&& 16);
再哈希，其目的是为了减少哈希冲突，使元素能够均匀的分布在不同的Segment上，从而提高容器的存取效率。假如哈希的质量差到极点，那么所有的元素都在一个Segment中，不仅存取元素缓慢，分段锁也会失去意义。我做了一个测试，不通过再哈希而直接执行哈希计算。
System.out.println(Integer.parseInt(&0001111&, 2) & 15);
System.out.println(Integer.parseInt(&0011111&, 2) & 15);
System.out.println(Integer.parseInt(&0111111&, 2) & 15);
System.out.println(Integer.parseInt(&1111111&, 2) & 15);
计算后输出的哈希值全是15，通过这个例子可以发现如果不进行再哈希，哈希冲突会非常严重，因为只要低位一样，无论高位是什么数，其哈希值总是一样。我们再把上面的二进制数据进行再哈希后结果如下，为了方便阅读，不足32位的高位补了0，每隔四位用竖线分割下。
可以发现每一位的数据都散列开了，通过这种再哈希能让数字的每一位都能参加到哈希运算当中，从而减少哈希冲突。ConcurrentHashMap通过以下哈希算法定位segment。
默认情况下segmentShift为28，segmentMask为15，再哈希后的数最大是32位二进制数据，向右无符号移动28位，意思是让高4位参与到hash运算中， (hash &&& segmentShift) & segmentMask的运算结果分别是4，15，7和8，可以看到hash值没有发生冲突。
final Segment&K,V& segmentFor(int hash) {
return segments[(hash &&& segmentShift) & segmentMask];
ConcurrentHashMap的get操作
Segment的get操作实现非常简单和高效。先经过一次再哈希，然后使用这个哈希值通过哈希运算定位到segment，再通过哈希算法定位到元素，代码如下：
public V get(Object key) {
int hash = hash(key.hashCode());
return segmentFor(hash).get(key, hash);
get操作的高效之处在于整个get过程不需要加锁，除非读到的值是空的才会加锁重读，我们知道HashTable容器的get方法是需要加锁的，那么ConcurrentHashMap的get操作是如何做到不加锁的呢？原因是它的get方法里将要使用的共享变量都定义成volatile，如用于统计当前Segement大小的count字段和用于存储值的HashEntry的value。定义成volatile的变量，能够在线程之间保持可见性，能够被多线程同时读，并且保证不会读到过期的值，但是只能被单线程写（有一种情况可以被多线程写，就是写入的值不依赖于原值），在get操作里只需要读不需要写共享变量count和value，所以可以不用加锁。之所以不会读到过期的值，是根据java内存模型的happen before原则，对volatile字段的写入操作先于读操作，即使两个线程同时修改和获取volatile变量，get操作也能拿到最新的值，这是用volatile替换锁的经典应用场景。
volatile V
在定位元素的代码里我们可以发现定位HashEntry和定位Segment的哈希算法虽然一样，都与数组的长度减去一相与，但是相与的值不一样，定位Segment使用的是元素的hashcode通过再哈希后得到的值的高位，而定位HashEntry直接使用的是再哈希后的值。其目的是避免两次哈希后的值一样，导致元素虽然在Segment里散列开了，但是却没有在HashEntry里散列开。
hash &&& segmentShift) & segmentMask//定位Segment所使用的hash算法
int index = hash & (tab.length - 1);// 定位HashEntry所使用的hash算法
ConcurrentHashMap的Put操作
由于put方法里需要对共享变量进行写入操作，所以为了线程安全，在操作共享变量时必须得加锁。Put方法首先定位到Segment，然后在Segment里进行插入操作。插入操作需要经历两个步骤，第一步判断是否需要对Segment里的HashEntry数组进行扩容，第二步定位添加元素的位置然后放在HashEntry数组里。
是否需要扩容。在插入元素前会先判断Segment里的HashEntry数组是否超过容量（threshold），如果超过阀值，数组进行扩容。值得一提的是，Segment的扩容判断比HashMap更恰当，因为HashMap是在插入元素后判断元素是否已经到达容量的，如果到达了就进行扩容，但是很有可能扩容之后没有新元素插入，这时HashMap就进行了一次无效的扩容。
如何扩容。扩容的时候首先会创建一个两倍于原容量的数组，然后将原数组里的元素进行再hash后插入到新的数组里。为了高效ConcurrentHashMap不会对整个容器进行扩容，而只对某个segment进行扩容。
ConcurrentHashMap的size操作
如果我们要统计整个ConcurrentHashMap里元素的大小，就必须统计所有Segment里元素的大小后求和。Segment里的全局变量count是一个volatile变量，那么在多线程场景下，我们是不是直接把所有Segment的count相加就可以得到整个ConcurrentHashMap大小了呢？不是的，虽然相加时可以获取每个Segment的count的最新值，但是拿到之后可能累加前使用的count发生了变化，那么统计结果就不准了。所以最安全的做法，是在统计size的时候把所有Segment的put，remove和clean方法全部锁住，但是这种做法显然非常低效。
因为在累加count操作过程中，之前累加过的count发生变化的几率非常小，所以ConcurrentHashMap的做法是先尝试2次通过不锁住Segment的方式来统计各个Segment大小，如果统计的过程中，容器的count发生了变化，则再采用加锁的方式来统计所有Segment的大小。
那么ConcurrentHashMap是如何判断在统计的时候容器是否发生了变化呢？使用modCount变量，在put , remove和clean方法里操作元素前都会将变量modCount进行加1，那么在统计size前后比较modCount是否发生变化，从而得知容器的大小是否发生变化。
JDK1.6源代码。
《Java并发编程实践》
原创文章，转载请注明： 转载自本文链接地址:
花名清英，并发网(ifeve.com)创始人，畅销书《Java并发编程的艺术》作者，蚂蚁金服技术专家。目前工作于支付宝微贷事业部，关注互联网金融，并发编程和敏捷实践。微信公众号aliqinying。
Latest posts by 方 腾飞 ()
Related posts:
(15 votes, average: 4.53 out of 5)
Loading...
TrackBack URL他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)关于synchronized锁在Spring事务中进行数据更新同步，仍出现线程安全问题
本文作者： 伯乐在线- 陶邦仁。未经作者许可，禁止转载！
欢迎加入伯乐在线 专栏作者。
1 问题描述
最近有小伙伴在做商品抽奖活动时，在对奖品库存进行扣减，有线程安全的问题，遂加锁synchronized进行同步，但发现加锁后并没有控制住库存线程安全的问题，导致库存仍被超发。
先简单介绍下，各层的技术架构：
中间层框架：Spring 4.1.0持久层：MyBatis 3.2.6MVC框架：Spring MVC 4.1.0
存在问题的代码：
publicvoidsaveMemberTicket(ApplyTicketReq applyTicketReq)throwsServiceException{
synchronized(this.class){
// 检查库存是否有剩余
preCheck(applyTicketReq);
// 扣减库存
modifyTicketAmount(applyTicketReq);
库存扣减超发问题具体描述：
当库存剩余为1时，线程1拿到锁进入同步代码块，扣减库存，线程2等待锁；当线程1执行完同步代码块时，线程2拿到锁，执行同步代码块，检查到的库存剩余仍为1；【此时，库存应该为0，产生库存扣减超发问题】
2 排查问题
排查问题开始之前，简单说下自己排查问题的几个原则（仅供参考）：
问题重现：一定要先重现问题，任何重现不了的问题，都不是问题。同理，任何存在的问题，都必然能再次重现。由近及远：先确认自己的代码无问题，然后再去确认外部代码无问题（如：框架代码，第三方代码等）。由外到内：程序就是一个IPO，有输入Input（如：参数、环境等）也有输出Out（如：结果、异常等），输出Out是问题的表象，先确定外部因素Input无问题，再确认程序代码逻辑无问题。由浅入深：其实就是由易到难、自上向下，先从上层应用排查问题，如：上层API、应用层、HTTP传输等，然后再确认底层应用排查问题，如：底层API、网络层、系统层、字节码、JVM等；
确定synchronized关键字是否起作用；【建议：尽量慎用synchronized关键字，非常影响程序性能】根据多线程并发测试，可以确认多线程之间是同步执行synchronized代码块，确认synchronized同步执行没问题。 确定Spring事务是否提交成功；查看Spring 事务配置：
&!--Transaction Support--&
&tx:advice id="useTxAdvice"transaction-manager="txManager"&
&tx:attributes&
&tx:method name="*remove*"propagation="REQUIRED"read-only="false"rollback-for="java.lang.Exception"no-rollback-for="com.xxx.exception.ServiceException"/&
&tx:method name="*save*"propagation="REQUIRED"read-only="false"rollback-for="java.lang.Exception"no-rollback-for="com.xxx.exception.ServiceException"/&
&tx:method name="*modify*"propagation="REQUIRED"read-only="false"rollback-for="java.lang.Exception"no-rollback-for="com.xxx.exception.ServiceException"/&
&tx:method name="*update*"propagation="REQUIRED"read-only="false"rollback-for="java.lang.Exception"no-rollback-for="com.xxx.exception.ServiceException"/&
&tx:method name="create*"propagation="REQUIRED"read-only="false"rollback-for="java.lang.Exception"no-rollback-for="com.xxx.exception.ServiceException"/&
&tx:method name="fill*"propagation="REQUIRED"read-only="false"rollback-for="java.lang.Exception"no-rollback-for="com.xxx.exception.ServiceException"/&
&tx:method name="cancel*"propagation="REQUIRED"read-only="false"rollback-for="java.lang.Exception"no-rollback-for="com.xxx.exception.ServiceException"/&
&tx:method name="*chang*"propagation="REQUIRED"read-only="false"rollback-for="java.lang.Exception"no-rollback-for="com.xxx.exception.ServiceException"/&
&tx:method name="handleLotteryResult"propagation="REQUIRED"read-only="false"rollback-for="java.lang.Exception"no-rollback-for="com.xxx.exception.ServiceException"/&
&tx:method name="find*"propagation="SUPPORTS"/&
&tx:method name="get*"propagation="SUPPORTS"/&
&tx:method name="query*"propagation="SUPPORTS"/&
&tx:method name="page*"propagation="SUPPORTS"/&
&tx:method name="count*"propagation="SUPPORTS"/&
&/tx:attributes&
&/tx:advice&
&!--把事务控制在Service层--&
&aop:config&
&aop:pointcut id="pc"expression="execution(public * com.xxx..service.*.*(..))"/&
&aop:advisor pointcut-ref="pc"advice-ref="useTxAdvice"/&
&/aop:config&
由于Spring事务是通过AOP实现的，所以在saveMemberTicket方法执行之前会有开启事务，之后会有提交事务逻辑。而synchronized代码块执行是在事务之内执行的，可以推断在synchronized代码块执行完时，事务还未提交，其他线程进入synchronized代码块后，读取的库存数据不是最新的。
3 解决问题
将synchronized关键字加入到Controller层，使synchronized锁的范围大于事务控制的范围。
@RequestMapping(value="applyTicket")
@ResponseBody
publicvoidapplyTicket(@FromJson ApplyTicketReq applyTicketReq)throwsException{
synchronized(String.valueOf(applyTicketReq.getMemberRoomId()).intern()){
synchronized(String.valueOf(applyTicketReq.getTicketId()).intern()){
service.saveMemberTicket(applyTicketReq);
responseMessage(ModelResult.CODE_200,ModelResult.SUCCESS);
4 总结问题
根据以上的排查过程，已经很清楚的确认了事务与锁之间存在的问题。由于事务范围大于锁代码块范围，在锁代码块执行完成后，此时事务还未提交，导致此时进入锁代码块的其他线程，读到的仍是原有的库存数据。
关于程序加锁自己的一点见解：
建议程序中尽量不要加锁；尽量在业务和代码层，解决线程安全的问题，实现无锁的线程安全；如果以上两点都做不到，一定要加锁，尽量使用java.util.concurrent包下的锁（因为是非阻塞锁，基于CAS算法实现，具体可以查看AQS类的实现）；如果以上三点仍然都做不到，一定要加阻塞锁：synchronized锁，两个原则：（1）尽量减小锁粒度；（2）尽量减小锁的代码范围；
打赏支持作者写出更多好文章，谢谢！
打赏作者 打赏支持作者写出更多好文章，谢谢！
任选一种支付方式
1赞收藏评论
关于作者：陶邦仁
专注于后端技术研究，前端技术略有涉猎，热衷于构建高性能、高可用网站，擅长于平台服务化、分布式服务、分布式存储等方面的解决方案。目前就职于千丁互联，任技术经理一职，负责社区产品技术研发。曾就职于京东，负责库存组缓存方案技术实现；曾就职于百度糯米，负责PC首页、APP个性化排单服务化解决方案。 个人主页· 我的文章· 62·
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
今日搜狐热点线程同步(使用了synchronized)和线程通讯(使用了wait,notify) - Android - ITeye知识库频道
什么是线程同步？
当使用多个线程来访问同一个数据时，非常容易出现线程安全问题(比如多个线程都在操作同一数据导致数据不一致),所以我们用同步机制来解决这些问题。实现同步机制有两个方法：1。同步代码块：synchronized(同一个数据){} 同一个数据：就是N条线程同时访问一个数据。
同步方法：public synchronized 数据返回类型 方法名(){}就是使用 synchronized 来修饰某个方法，则该方法称为同步方法。对于同步方法而言，无需显示指定同步监视器，同步方法的同步监视器是 this 也就是该对象的本身（这里指的对象本身有点含糊，其实就是调用该同步方法的对象）通过使用同步方法，可非常方便的将某类变成线程安全的类，具有如下特征：1，该类的对象可以被多个线程安全的访问。2，每个线程调用该对象的任意方法之后，都将得到正确的结果。3，每个线程调用该对象的任意方法之后，该对象状态依然保持合理状态。注：synchronized关键字可以修饰方法，也可以修饰代码块，但不能修饰构造器，属性等。实现同步机制注意以下几点：
安全性高，性能低，在多线程用。性能高，安全性低，在单线程用。1，不要对线程安全类的所有方法都进行同步，只对那些会改变共享资源方法的进行同步。2，如果可变类有两种运行环境，当线程环境和多线程环境则应该为该可变类提供两种版本：线程安全版本和线程不安全版本(没有同步方法和同步块)。在单线程中环境中，使用线程不安全版本以保证性能，在多线程中使用线程安全版本.
线程通讯：
为什么要使用线程通讯？
当使用synchronized 来修饰某个共享资源时(分同步代码块和同步方法两种情况）,当某个线程获得共享资源的锁后就可以执行相应的代码段，直到该线程运行完该代码段后才释放对该共享资源的锁，让其他线程有机会执行对该共享资源的修改。当某个线程占有某个共享资源的锁时，如果另外一个线程也想获得这把锁运行就需要使用wait() 和notify()/notifyAll()方法来进行线程通讯了。Java.lang.object 里的三个方法wait() notify()
notifyAll()wait方法导致当前线程等待，直到其他线程调用同步监视器的notify方法或notifyAll方法来唤醒该线程。wait(mills)方法都是等待指定时间后自动苏醒，调用wait方法的当前线程会释放该同步监视器的锁定，可以不用notify或notifyAll方法把它唤醒。notify()唤醒在同步监视器上等待的单个线程，如果所有线程都在同步监视器上等待，则会选择唤醒其中一个线程，选择是任意性的，只有当前线程放弃对该同步监视器的锁定后，也就是使用wait方法后，才可以执行被唤醒的线程。notifyAll()方法唤醒在同步监视器上等待的所有的线程。只用当前线程放弃对该同步监视器的锁定后，才可以执行被唤醒的线程。
-------------------------------------------------另外的总结2--------------------------------------------
线程的同步 原子操作：根据Java规范，对于基本类型的赋值或者返回值操作，是原子操作。但这里的基本数据类型不包括long和double, 因为JVM看到的基本存储单位是32位，而long 和double都要用64位来表示。所以无法在一个时钟周期内完成。 自增操作（++）不是原子操作，因为它涉及到一次读和一次写。 原子操作：由一组相关的操作完成，这些操作可能会操纵与其它的线程共享的资源，为了保证得到正确的运算结果，一个线程在执行原子操作其间，应该采取其他的措施使得其他的线程不能操纵共享资源。 同步代码块：为了保证每个线程能够正常执行原子操作，Java引入了同步机制，具体的做法是在代表原子操作的程序代码前加上synchronized标记，这样的代码被称为同步代码块。 同步锁：每个JAVA对象都有且只有一个同步锁，在任何时刻，最多只允许一个线程拥有这把锁。 当一个线程试图访问带有synchronized(this)标记的代码块时，必须获得 this关键字引用的对象的锁，在以下的两种情况下，本线程有着不同的命运。 1、 假如这个锁已经被其它的线程占用，JVM就会把这个线程放到本对象的锁池中。本线程进入阻塞状态。锁池中可能有很多的线程，等到其他的线程释放了锁，JVM就会从锁池中随机取出一个线程，使这个线程拥有锁，并且转到就绪状态。 2、 假如这个锁没有被其他线程占用，本线程会获得这把锁，开始执行同步代码块。 （一般情况下在执行同步代码块时不会释放同步锁，但也有特殊情况会释放对象锁 如在执行同步代码块时，遇到异常而导致线程终止，锁会被释放；在执行代码块时，执行了锁所属对象的wait()方法，这个线程会释放对象锁，进入对象的等待池中） 线程同步的特征： 1、 如果一个同步代码块和非同步代码块同时操作共享资源，仍然会造成对共享资源的竞争。因为当一个线程执行一个对象的同步代码块时，其他的线程仍然可以执行对象的非同步代码块。（所谓的线程之间保持同步，是指不同的线程在执行同一个对象的同步代码块时，因为要获得对象的同步锁而互相牵制） 2、 每个对象都有唯一的同步锁 3、 在静态方法前面可以使用synchronized修饰符。 4、 当一个线程开始执行同步代码块时，并不意味着必须以不间断的方式运行，进入同步代码块的线程可以执行Thread.sleep()或执行Thread.yield()方法，此时它并不释放对象锁，只是把运行的机会让给其他的线程。 5、 Synchronized声明不会被继承，如果一个用synchronized修饰的方法被子类覆盖，那么子类中这个方法不在保持同步，除非用synchronized修饰。 线程安全的类： 1、 这个类的对象可以同时被多个线程安全的访问。 2、 每个线程都能正常的执行原子操作，得到正确的结果。 3、 在每个线程的原子操作都完成后，对象处于逻辑上合理的状态。 释放对象的锁： 1、 执行完同步代码块就会释放对象的锁 2、 在执行同步代码块的过程中，遇到异常而导致线程终止，锁也会被释放 3、 在执行同步代码块的过程中，执行了锁所属对象的wait()方法，这个线程会释放对象锁，进入对象的等待池。 死锁 当一个线程等待由另一个线程持有的锁，而后者正在等待已被第一个线程持有的锁时，就会发生死锁。JVM不监测也不试图避免这种情况，因此保证不发生死锁就成了程序员的责任。 如何避免死锁 一个通用的经验法则是：当几个线程都要访问共享资源A、B、C 时，保证每个线程都按照同样的顺序去访问他们。 线程通信 Java.lang.Object类中提供了两个用于线程通信的方法 1、 wait():执行了该方法的线程释放对象的锁，JVM会把该线程放到对象的等待池中。该线程等待其它线程唤醒 2、 notify():执行该方法的线程唤醒在对象的等待池中等待的一个线程，JVM从对象的等待池中随机选择一个线程，把它转到对象的锁池中。
----------------------------------------------------线程同步的总结3---------------------------------------
我们可以在计算机上运行各种计算机软件程序。每一个运行的程序可能包括多个独立运行的线程（Thread）。 线程（Thread）是一份独立运行的程序，有自己专用的运行栈。线程有可能和其他线程共享一些资源，比如，内存，文件，数据库等。 当多个线程同时读写同一份共享资源的时候，可能会引起冲突。这时候，我们需要引入线程“同步”机制，即各位线程之间要有个先来后到，不能一窝蜂挤上去抢作一团。 同步这个词是从英文synchronize（使同时发生）翻译过来的。我也不明白为什么要用这个很容易引起误解的词。既然大家都这么用，咱们也就只好这么将就。 线程同步的真实意思和字面意思恰好相反。线程同步的真实意思，其实是“排队”：几个线程之间要排队，一个一个对共享资源进行操作，而不是同时进行操作。 因此，关于线程同步，需要牢牢记住的第一点是：线程同步就是线程排队。同步就是排队。线程同步的目的就是避免线程“同步”执行。这可真是个无聊的绕口令。 关于线程同步，需要牢牢记住的第二点是 “共享”这两个字。只有共享资源的读写访问才需要同步。如果不是共享资源，那么就根本没有同步的必要。 关于线程同步，需要牢牢记住的第三点是，只有“变量”才需要同步访问。如果共享的资源是固定不变的，那么就相当于“常量”，线程同时读取常量也不需要同步。至少一个线程修改共享资源，这样的情况下，线程之间就需要同步。 关于线程同步，需要牢牢记住的第四点是：多个线程访问共享资源的代码有可能是同一份代码，也有可能是不同的代码；无论是否执行同一份代码，只要这些线程的代码访问同一份可变的共享资源，这些线程之间就需要同步。 为了加深理解，下面举几个例子。 有两个采购员，他们的工作内容是相同的，都是遵循如下的步骤： （1）到市场上去，寻找并购买有潜力的样品。 （2）回到公司，写报告。 这两个人的工作内容虽然一样，他们都需要购买样品，他们可能买到同样种类的样品，但是他们绝对不会购买到同一件样品，他们之间没有任何共享资源。所以，他们可以各自进行自己的工作，互不干扰。 这两个采购员就相当于两个线程；两个采购员遵循相同的工作步骤，相当于这两个线程执行同一段代码。 下面给这两个采购员增加一个工作步骤。采购员需要根据公司的“布告栏”上面公布的信息，安排自己的工作计划。 这两个采购员有可能同时走到布告栏的前面，同时观看布告栏上的信息。这一点问题都没有。因为布告栏是只读的，这两个采购员谁都不会去修改布告栏上写的信息。 下面增加一个角色。一个办公室行政人员这个时候，也走到了布告栏前面，准备修改布告栏上的信息。 如果行政人员先到达布告栏，并且正在修改布告栏的内容。两个采购员这个时候，恰好也到了。这两个采购员就必须等待行政人员完成修改之后，才能观看修改后的信息。 如果行政人员到达的时候，两个采购员已经在观看布告栏了。那么行政人员需要等待两个采购员把当前信息记录下来之后，才能够写上新的信息。 上述这两种情况，行政人员和采购员对布告栏的访问就需要进行同步。因为其中一个线程（行政人员）修改了共享资源（布告栏）。而且我们可以看到，行政人员的工作流程和采购员的工作流程（执行代码）完全不同，但是由于他们访问了同一份可变共享资源（布告栏），所以他们之间需要同步。 同步锁 前面讲了为什么要线程同步，下面我们就来看如何才能线程同步。 线程同步的基本实现思路还是比较容易理解的。我们可以给共享资源加一把锁，这把锁只有一把钥匙。哪个线程获取了这把钥匙，才有权利访问该共享资源。 生活中，我们也可能会遇到这样的例子。一些超市的外面提供了一些自动储物箱。每个储物箱都有一把锁，一把钥匙。人们可以使用那些带有钥匙的储物箱，把东西放到储物箱里面，把储物箱锁上，然后把钥匙拿走。这样，该储物箱就被锁住了，其他人不能再访问这个储物箱。（当然，真实的储物箱钥匙是可以被人拿走复制的，所以不要把贵重物品放在超市的储物箱里面。于是很多超市都采用了电子密码锁。） 线程同步锁这个模型看起来很直观。但是，还有一个严峻的问题没有解决，这个同步锁应该加在哪里？ 当然是加在共享资源上了。反应快的读者一定会抢先回答。 没错，如果可能，我们当然尽量把同步锁加在共享资源上。一些比较完善的共享资源，比如，文件系统，数据库系统等，自身都提供了比较完善的同步锁机制。我们不用另外给这些资源加锁，这些资源自己就有锁。 但是，大部分情况下，我们在代码中访问的共享资源都是比较简单的共享对象。这些对象里面没有地方让我们加锁。 读者可能会提出建议：为什么不在每一个对象内部都增加一个新的区域，专门用来加锁呢？这种设计理论上当然也是可行的。问题在于，线程同步的情况并不是很普遍。如果因为这小概率事件，在所有对象内部都开辟一块锁空间，将会带来极大的空间浪费。得不偿失。 于是，现代的编程语言的设计思路都是把同步锁加在代码段上。确切的说，是把同步锁加在“访问共享资源的代码段”上。这一点一定要记住，同步锁是加在代码段上的。 同步锁加在代码段上，就很好地解决了上述的空间浪费问题。但是却增加了模型的复杂度，也增加了我们的理解难度。 现在我们就来仔细分析“同步锁加在代码段上”的线程同步模型。 首先，我们已经解决了同步锁加在哪里的问题。我们已经确定，同步锁不是加在共享资源上，而是加在访问共享资源的代码段上。 其次，我们要解决的问题是，我们应该在代码段上加什么样的锁。这个问题是重点中的重点。这是我们尤其要注意的问题：访问同一份共享资源的不同代码段，应该加上同一个同步锁；如果加的是不同的同步锁，那么根本就起不到同步的作用，没有任何意义。 这就是说，同步锁本身也一定是多个线程之间的共享对象。 Java语言的synchronized关键字 为了加深理解，举几个代码段同步的例子。 不同语言的同步锁模型都是一样的。只是表达方式有些不同。这里我们以当前最流行的Java语言为例。Java语言里面用synchronized关键字给代码段加锁。整个语法形式表现为 synchronized(同步锁) {
// 访问共享资源，需要同步的代码段 } 这里尤其要注意的就是，同步锁本身一定要是共享的对象。 … f1() { Object lock1 = new Object(); // 产生一个同步锁 synchronized(lock1){
// 代码段 A // 访问共享资源 resource1 // 需要同步 } } 上面这段代码没有任何意义。因为那个同步锁是在函数体内部产生的。每个线程调用这段代码的时候，都会产生一个新的同步锁。那么多个线程之间，使用的是不同的同步锁。根本达不到同步的目的。 同步代码一定要写成如下的形式，才有意义。 public static final Object lock1 = new Object(); … f1() { synchronized(lock1){ // lock1 是公用同步锁
// 代码段 A // 访问共享资源 resource1 // 需要同步 } 你不一定要把同步锁声明为static或者public，但是你一定要保证相关的同步代码之间，一定要使用同一个同步锁。 讲到这里，你一定会好奇，这个同步锁到底是个什么东西。为什么随便声明一个Object对象，就可以作为同步锁？ 在Java里面，同步锁的概念就是这样的。任何一个Object Reference都可以作为同步锁。我们可以把Object Reference理解为对象在内存分配系统中的内存地址。因此，要保证同步代码段之间使用的是同一个同步锁，我们就要保证这些同步代码段的synchronized关键字使用的是同一个Object Reference，同一个内存地址。这也是为什么我在前面的代码中声明lock1的时候，使用了final关键字，这就是为了保证lock1的Object Reference在整个系统运行过程中都保持不变。 一些求知欲强的读者可能想要继续深入了解synchronzied(同步锁)的实际运行机制。Java虚拟机规范中（你可以在google用“JVM Spec”等关键字进行搜索），有对synchronized关键字的详细解释。synchronized会编译成 monitor enter, … monitor exit之类的指令对。Monitor就是实际上的同步锁。每一个Object Reference在概念上都对应一个monitor。 这些实现细节问题，并不是理解同步锁模型的关键。我们继续看几个例子，加深对同步锁模型的理解。 public static final Object lock1 = new Object(); … f1() { synchronized(lock1){ // lock1 是公用同步锁
// 代码段 A // 访问共享资源 resource1 // 需要同步 } } … f2() { synchronized(lock1){ // lock1 是公用同步锁
// 代码段 B // 访问共享资源 resource1 // 需要同步 } } 上述的代码中，代码段A和代码段B就是同步的。因为它们使用的是同一个同步锁lock1。 如果有10个线程同时执行代码段A，同时还有20个线程同时执行代码段B，那么这30个线程之间都是要进行同步的。 这30个线程都要竞争一个同步锁lock1。同一时刻，只有一个线程能够获得lock1的所有权，只有一个线程可以执行代码段A或者代码段B。其他竞争失败的线程只能暂停运行，进入到该同步锁的就绪（Ready）队列。 每一个同步锁下面都挂了几个线程队列，包括就绪（Ready）队列，待召（Waiting）队列等。比如，lock1对应的就绪队列就可以叫做lock1 - ready queue。每个队列里面都可能有多个暂停运行的线程。 注意，竞争同步锁失败的线程进入的是该同步锁的就绪（Ready）队列，而不是后面要讲述的待召队列（Waiting Queue，也可以翻译为等待队列）。就绪队列里面的线程总是时刻准备着竞争同步锁，时刻准备着运行。而待召队列里面的线程则只能一直等待，直到等到某个信号的通知之后，才能够转移到就绪队列中，准备运行。 成功获取同步锁的线程，执行完同步代码段之后，会释放同步锁。该同步锁的就绪队列中的其他线程就继续下一轮同步锁的竞争。成功者就可以继续运行，失败者还是要乖乖地待在就绪队列中。 因此，线程同步是非常耗费资源的一种操作。我们要尽量控制线程同步的代码段范围。同步的代码段范围越小越好。我们用一个名词“同步粒度”来表示同步代码段的范围。 同步粒度 在Java语言里面，我们可以直接把synchronized关键字直接加在函数的定义上。 比如。 … synchronized … f1() {
// f1 代码段 } 这段代码就等价于 … f1() {
synchronized(this){ // 同步锁就是对象本身
// f1 代码段
} } 同样的原则适用于静态（static）函数 比如。 … static synchronized … f1() {
// f1 代码段 } 这段代码就等价于 …static … f1() {
synchronized(Class.forName(…)){ // 同步锁是类定义本身
// f1 代码段
} } 但是，我们要尽量避免这种直接把synchronized加在函数定义上的偷懒做法。因为我们要控制同步粒度。同步的代码段越小越好。synchronized控制的范围越小越好。 我们不仅要在缩小同步代码段的长度上下功夫，我们同时还要注意细分同步锁。 比如，下面的代码 public static final Object lock1 = new Object(); … f1() { synchronized(lock1){ // lock1 是公用同步锁
// 代码段 A // 访问共享资源 resource1 // 需要同步 } } … f2() { synchronized(lock1){ // lock1 是公用同步锁
// 代码段 B // 访问共享资源 resource1 // 需要同步 } } … f3() { synchronized(lock1){ // lock1 是公用同步锁
// 代码段 C // 访问共享资源 resource2 // 需要同步 } } … f4() { synchronized(lock1){ // lock1 是公用同步锁
// 代码段 D // 访问共享资源 resource2 // 需要同步 } } 上述的4段同步代码，使用同一个同步锁lock1。所有调用4段代码中任何一段代码的线程，都需要竞争同一个同步锁lock1。 我们仔细分析一下，发现这是没有必要的。 因为f1()的代码段A和f2()的代码段B访问的共享资源是resource1，f3()的代码段C和f4()的代码段D访问的共享资源是resource2，它们没有必要都竞争同一个同步锁lock1。我们可以增加一个同步锁lock2。f3()和f4()的代码可以修改为： public static final Object lock2 = new Object(); … f3() { synchronized(lock2){ // lock2 是公用同步锁
// 代码段 C // 访问共享资源 resource2 // 需要同步 } } … f4() { synchronized(lock2){ // lock2 是公用同步锁
// 代码段 D // 访问共享资源 resource2 // 需要同步 } } 这样，f1()和f2()就会竞争lock1，而f3()和f4()就会竞争lock2。这样，分开来分别竞争两个锁，就可以大大较少同步锁竞争的概率，从而减少系统的开销。 信号量 同步锁模型只是最简单的同步模型。同一时刻，只有一个线程能够运行同步代码。 有的时候，我们希望处理更加复杂的同步模型，比如生产者/消费者模型、读写同步模型等。这种情况下，同步锁模型就不够用了。我们需要一个新的模型。这就是我们要讲述的信号量模型。 信号量模型的工作方式如下：线程在运行的过程中，可以主动停下来，等待某个信号量的通知；这时候，该线程就进入到该信号量的待召（Waiting）队列当中；等到通知之后，再继续运行。 很多语言里面，同步锁都由专门的对象表示，对象名通常叫Monitor。 同样，在很多语言中，信号量通常也有专门的对象名来表示，比如，Mutex，Semphore。 信号量模型要比同步锁模型复杂许多。一些系统中，信号量甚至可以跨进程进行同步。另外一些信号量甚至还有计数功能，能够控制同时运行的线程数。 我们没有必要考虑那么复杂的模型。所有那些复杂的模型，都是最基本的模型衍生出来的。只要掌握了最基本的信号量模型——“等待/通知”模型，复杂模型也就迎刃而解了。 我们还是以Java语言为例。Java语言里面的同步锁和信号量概念都非常模糊，没有专门的对象名词来表示同步锁和信号量，只有两个同步锁相关的关键字——volatile和synchronized。 这种模糊虽然导致概念不清，但同时也避免了Monitor、Mutex、Semphore等名词带来的种种误解。我们不必执着于名词之争，可以专注于理解实际的运行原理。 在Java语言里面，任何一个Object Reference都可以作为同步锁。同样的道理，任何一个Object Reference也可以作为信号量。 Object对象的wait()方法就是等待通知，Object对象的notify()方法就是发出通知。 具体调用方法为 （1）等待某个信号量的通知 public static final Object signal = new Object(); … f1() { synchronized(singal) { // 首先我们要获取这个信号量。这个信号量同时也是一个同步锁
// 只有成功获取了signal这个信号量兼同步锁之后，我们才可能进入这段代码
signal.wait(); // 这里要放弃信号量。本线程要进入signal信号量的待召（Waiting）队列 // 可怜。辛辛苦苦争取到手的信号量，就这么被放弃了
// 等到通知之后，从待召（Waiting）队列转到就绪（Ready）队列里面 // 转到了就绪队列中，离CPU核心近了一步，就有机会继续执行下面的代码了。 // 仍然需要把signal同步锁竞争到手，才能够真正继续执行下面的代码。命苦啊。
… } } 需要注意的是，上述代码中的signal.wait()的意思。signal.wait()很容易导致误解。signal.wait()的意思并不是说，signal开始wait，而是说，运行这段代码的当前线程开始wait这个signal对象，即进入signal对象的待召（Waiting）队列。 （2）发出某个信号量的通知 … f2() { synchronized(singal) { // 首先，我们同样要获取这个信号量。同时也是一个同步锁。
// 只有成功获取了signal这个信号量兼同步锁之后，我们才可能进入这段代码 signal.notify(); // 这里，我们通知signal的待召队列中的某个线程。 // 如果某个线程等到了这个通知，那个线程就会转到就绪队列中 // 但是本线程仍然继续拥有signal这个同步锁，本线程仍然继续执行 // 嘿嘿，虽然本线程好心通知其他线程， // 但是，本线程可没有那么高风亮节，放弃到手的同步锁 // 本线程继续执行下面的代码
… } } 需要注意的是，signal.notify()的意思。signal.notify()并不是通知signal这个对象本身。而是通知正在等待signal信号量的其他线程。 以上就是Object的wait()和notify()的基本用法。 实际上，wait()还可以定义等待时间，当线程在某信号量的待召队列中，等到足够长的时间，就会等无可等，无需再等，自己就从待召队列转移到就绪队列中了。 另外，还有一个notifyAll()方法，表示通知待召队列里面的所有线程。 这些细节问题，并不对大局产生影响。
----------------------------------------------------------------------------------------线程同步的总结4-------------------------------------------------------------------------
总的说来，synchronized关键字可以作为函数的修饰符，也可作为函数内的语句，也就是平时说的同步方法和同步语句块。如果再细的分类，synchronized可作用于instance变量、object reference（对象引用）、static函数和class literals(类名称字面常量)身上。
在进一步阐述之前，我们需要明确几点：
A．无论synchronized关键字加在方法上还是对象上，它取得的锁都是对象，而不是把一段代码或函数当作锁――而且同步方法很可能还会被其他线程的对象访问。
B．每个对象只有一个锁（lock）与之相关联。
C．实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。
接着来讨论synchronized用到不同地方对代码产生的影响：
假设P1、P2是同一个类的不同对象，这个类中定义了以下几种情况的同步块或同步方法，P1、P2就都可以调用它们。
把synchronized当作函数修饰符时，示例代码如下：
Public synchronized void methodAAA()
这也就是同步方法，那这时synchronized锁定的是哪个对象呢？它锁定的是调用这个同步方法对象。也就是说，当一个对象P1在不同的线程中执行这个同步方法时，它们之间会形成互斥，达到同步的效果。但是这个对象所属的Class所产生的另一对象P2却可以任意调用这个被加了synchronized关键字的方法。
上边的示例代码等同于如下代码：
public void methodAAA()
synchronized (this)
(1)处的this指的是什么呢？它指的就是调用这个方法的对象，如P1。可见同步方法实质是将synchronized作用于object reference。――那个拿到了P1对象锁的线程，才可以调用P1的同步方法，而对P2而言，P1这个锁与它毫不相干，程序也可能在这种情形下摆脱同步机制的控制，造成数据混乱：（
2．同步块，示例代码如下：
public void method3(SomeObject so)
synchronized(so)
这时，锁就是so这个对象，谁拿到这个锁谁就可以运行它所控制的那段代码。当有一个明确的对象作为锁时，就可以这样写程序，但当没有明确的对象作为锁，只是想让一段代码同步时，可以创建一个特殊的instance变量（它得是一个对象）来充当锁：
class Foo implements Runnable
private byte[] lock = new byte[0];
// 特殊的instance变量
Public void methodA()
synchronized(lock) { //… }
注：零长度的byte数组对象创建起来将比任何对象都经济――查看编译后的字节码：生成零长度的byte[]对象只需3条操作码，而Object lock = new Object()则需要7行操作码。
3．将synchronized作用于static 函数，示例代码如下：
public synchronized static void methodAAA()
// 同步的static 函数
public void methodBBB()
synchronized(Foo.class)
class literal(类名称字面常量)
代码中的methodBBB()方法是把class literal作为锁的情况，它和同步的static函数产生的效果是一样的，取得的锁很特别，是当前调用这个方法的对象所属的类（Class，而不再是由这个Class产生的某个具体对象了）。
记得在《Effective Java》一书中看到过将 Foo.class和 P1.getClass()用于作同步锁还不一样，不能用P1.getClass()来达到锁这个Class的目的。P1指的是由Foo类产生的对象。
可以推断：如果一个类中定义了一个synchronized的static函数A，也定义了一个synchronized 的instance函数B，那么这个类的同一对象Obj在多线程中分别访问A和B两个方法时，不会构成同步，因为它们的锁都不一样。A方法的锁是Obj这个对象，而B的锁是Obj所属的那个Class。
小结如下：
搞清楚synchronized锁定的是哪个对象，就能帮助我们设计更安全的多线程程序。
还有一些技巧可以让我们对共享资源的同步访问更加安全：
定义private 的instance变量+它的 get方法，而不要定义public/protected的instance变量。如果将变量定义为public，对象在外界可以绕过同步方法的控制而直接取得它，并改动它。这也是JavaBean的标准实现方式之一。
如果instance变量是一个对象，如数组或ArrayList什么的，那上述方法仍然不安全，因为当外界对象通过get方法拿到这个instance对象的引用后，又将其指向另一个对象，那么这个private变量也就变了，岂不是很危险。 这个时候就需要将get方法也加上synchronized同步，并且，只返回这个private对象的clone()――这样，调用端得到的就是对象副本的引用了。
标签: 飞雪无情, java线程, java同步, java线程通讯