在使用Mybatis的时候，有时候我们会有这么一种需求：我们希望通过Mybatis查询某一个表返回的结果是一个Map（HashMap），而这个Map的Key是表的一个字段，Value是另一个字段。然而当我们按照Mybatis的做法，指定查询Mapper语句的resultType为map时返回的结果是一个List。本文的例子将采用一个简单的方法，直接返回map

在理解Condition之前首先要明白两个概念： 等待队列：等待获取锁的线程构成的队列，称为等待队列 条件队列：已经获取到锁的线程由于某种原因释放了锁，等待signal信号，而构成的队列称为条件队列

Semaphore的实现和ReentrantLock的实现很相似，都有公平和非公平两种实现。本文的分析可以对比 LOCK源码分析 和 CountDownLatch源码分析 对比看。这样可以看出AQS的几条关键执行路径。

ReentrantLock是显示锁，Synchronized叫内置锁是JDK1.6中由道格李引入的。他们的关系就像 wait/notify 和 condition。RenentrantLock的实现和CountDownLatch的实现基本相同，唯一的区别是ReentrantLock有两种实现，分别对应公平锁和非公平锁。

前面写过一篇文章AQS源码分析的时候介绍过AQS是java并发编程的基础，Java并发包下面提供的同步工具类基本上都是以AQS构建的，一个同步类的实现主要分为三步： 该同步工具类 ，定义内部类实现AQS 定义该内部类的构造方法设置同步状态 实现tryAcquire/tryRelease方法

AbstractQueudSynchronizer（AQS）是道格李java并发编程的基础，内部主要包括Node和ConditionObject两个内部类，基于Node节点构建了一个FIFO队列，用来存储等待锁的线程的队列。基于ConditionObject节点也构造了一个FIFO队列，用于存储因为某种原因已经获取到锁而又主动释放锁的线程的队列。在concurrent包下面的大部分的工具类都是以他

并发编程的所有问题，最后都转换成了，“有状态bean”的状态的同步与互斥修改问题。而最后提出的解决“有状态bean”的同步与互斥修改问题的方案是为所有修改这个状态的方法都加上锁，这样也就可以保证他们在修改bean的状态的时候是顺序进行的。但是这样整个过程的瓶颈也就是被加锁的这段代码。由此就产生了很多对程序加锁的优化思想，从整体上来看，可以分为两个部分：对单个锁的算法的优化。和对锁粒度的细分

在java虚拟机上面每个对象和类在逻辑上面都是和一个监视器相关联的，对于对象来说，监视器保护的是对象的实例变量，对于类来说，监视器保护的是类的类变量，为了实现监视器的排他能力，JVM为每个对象分配一个锁（称为内置锁），任何时候只有一个线程可以获得这个锁，当前线程访问实例对象不需要重新获取锁（锁的重入，在后面会介绍）， 当只有一个线程获取到该对象的锁之后，在他释放这个锁之前其他线程只能等待。

为了简化线程同步与互斥的相关操作JDK，提供了大约4中同步与互斥的工具类： 闭锁（CountDownLatch），栅栏（CyclicBarrier），阻塞队列（BlockingQueue）,信号量（semaphore）。本文将对比分析四种同步工具类的使用范例，和应用场景。

总的来说synchronized主要是解决线程互斥性问题，volatitle主要是解决线程可见性的问题