自己去参考一下jdk5或6的api文档，里面已经实现了
并发队列是一个基于链接节点的无界线程安全队列，它采用先进先出的规则对节点进行排序，当我们添加一个元素的时候，它会添加到队列的尾部，当我们获取一个元素时，它会返回队列头部的元素。它采用了“wait－free”算法来实现，该算法在Michael
&Scott算法上进行了一些修改。
入队列
入队列就是将入队节点添加到队列的尾部。为了方便理解入队时队列的变化，以及head节点和tair节点的变化，每添加一个节点我就做了一个队列的快照图。
第一步添加元素1。队列更新head节点的next节点为元素1节点。又因为tail节点默认情况下等于head节点，所以它们的next节点都指向元素1节点。
第二步添加元素2。队列首先设置元素1节点的next节点为元素2节点，然后更新tail节点指向元素2节点。
第三步添加元素3，设置tail节点的next节点为元素3节点。
第四步添加元素4，设置元素3的next节点为元素4节点，然后将tail节点指向元素4节点。
通过debug入队过程并观察head节点和tail节点的变化，发现入队主要做两件事情，
第一是将入队节点设置成当前队列尾节点的下一个节点。
第二是更新tail节点，如果tail节点的next节点不为空，则将入队节点设置成tail节点，如果tail节点的next节点为空，则将入队节点设置成tail的next节点，所以tail节点不总是尾节点，理解这一点对于我们研究源码会非常有帮助。
上面的分析让我们从单线程入队的角度来理解入队过程，但是多个线程同时进行入队情况就变得更加复杂，因为可能会出现其他线程插队的情况。如果有一个线程正在入队，那么它必须先获取尾节点，然后设置尾节点的下一个节点为入队节点，但这时可能有另外一个线程插队了，那么队列的尾节点就会发生变化，这时当前线程要暂停入队操作，然后重新获取尾节点。让我们再通过源码来详细分析下它是如何使用CAS算法来入队的。
public boolean offer(E e) {
if (e == null) throw new NullPointerException()
//入队前，创建一个入队节点
Node</e><e> n = new Node</e><e>(e)
retry:
//死循环，入队不成功反复入队。
for () {
//创建一个指向tail节点的引用
Node</e><e> t = tail
//p用来表示队列的尾节点，默认情况下等于tail节点。
Node</e><e> p = t
for (int hops = 0 hops++) {
//获得p节点的下一个节点。
Node</e><e> next = succ(p)
//next节点不为空，说明p不是尾节点，需要更新p后在将它指向next节点
if (next != null) {
//循环了两次及其以上，并且当前节点还是不等于尾节点
if (hops > HOPS && t != tail)
continue retry
p = next
}
//如果p是尾节点，则设置p节点的next节点为入队节点。
else if (p.casNext(null, n)) {
//如果tail节点有大于等于1个next节点，则将入队节点设置成tair节点，更新失败了也没关系，因为失败了表示有其他线程成功更新了tair节点。
if (hops >= HOPS)
casTail(t, n) // 更新tail节点，允许失败
return true
}
// p有next节点,表示p的next节点是尾节点，则重新设置p节点
else {
p = succ(p)
}
}
}
}
从源代码角度来看整个入队过程主要做二件事情。
第一步定位尾节点。tail节点并不总是尾节点，所以每次入队都必须先通过tail节点来找到尾节点，尾节点可能就是tail节点，也可能是tail节点的next节点。代码中循环体中的第一个if就是判断tail是否有next节点，有则表示next节点可能是尾节点。获取tail节点的next节点需要注意的是p节点等于p的next节点的情况，只有一种可能就是p节点和p的next节点都等于空，表示这个队列刚初始化，正准备添加第一次节点，所以需要返回head节点。获取p节点的next节点代码如下
final Node</e><e> succ(Node</e><e> p) {
Node</e><e> next = p.getNext()
return (p == next) ? head : next
}
第二步设置入队节点为尾节点。p.casNext(null, n)方法用于将入队节点设置为当前队列尾节点的next节点，p如果是null表示p是当前队列的尾节点，如果不为null表示有其他线程更新了尾节点，则需要重新获取当前队列的尾节点。
hops的设计意图。上面分析过对于先进先出的队列入队所要做的事情就是将入队节点设置成尾节点，doug lea写的代码和逻辑还是稍微有点复杂。那么我用以下方式来实现行不行？
public boolean offer(E e) {
if (e == null)
throw new NullPointerException()
Node</e><e> n = new Node</e><e>(e)
for () {
Node</e><e> t = tail
if (t.casNext(null, n) && casTail(t, n)) {
return true
}
}
}
让tail节点永远作为队列的尾节点，这样实现代码量非常少，而且逻辑非常清楚和易懂。但是这么做有个缺点就是每次都需要使用循环CAS更新tail节点。如果能减少CAS更新tail节点的次数，就能提高入队的效率，所以doug
lea使用hops变量来控制并减少tail节点的更新频率，并不是每次节点入队后都将 tail节点更新成尾节点，而是当
tail节点和尾节点的距离大于等于常量HOPS的值（默认等于1）时才更新tail节点，tail和尾节点的距离越长使用CAS更新tail节点的次数就会越少，但是距离越长带来的负面效果就是每次入队时定位尾节点的时间就越长，因为循环体需要多循环一次来定位出尾节点，但是这样仍然能提高入队的效率，因为从本质上来看它通过增加对volatile变量的读操作来减少了对volatile变量的写操作，而对volatile变量的写操作开销要远远大于读操作，所以入队效率会有所提升。
private static final int HOPS = 1还有一点需要注意的是入队方法永远返回true，所以不要通过返回值判断入队是否成功。
4. 出队列
出队列的就是从队列里返回一个节点元素，并清空该节点对元素的引用。让我们通过每个节点出队的快照来观察下head节点的变化。
从上图可知，并不是每次出队时都更新head节点，当head节点里有元素时，直接弹出head节点里的元素，而不会更新head节点。只有当head节点里没有元素时，出队操作才会更新head节点。这种做法也是通过hops变量来减少使用CAS更新head节点的消耗，从而提高出队效率。让我们再通过源码来深入分析下出队过程。
public E poll() {
Node</e><e> h = head
// p表示头节点，需要出队的节点
Node</e><e> p = h
for (int hops = 0 hops++) {
// 获取p节点的元素
E item = p.getItem()
// 如果p节点的元素不为空，使用CAS设置p节点引用的元素为null,如果成功则返回p节点的元素。
if (item != null && p.casItem(item, null)) {
if (hops >= HOPS) {
//将p节点下一个节点设置成head节点
Node</e><e> q = p.getNext()
updateHead(h, (q != null) ? q : p)
}
return item
}
// 如果头节点的元素为空或头节点发生了变化，这说明头节点已经被另外一个线程修改了。那么获取p节点的下一个节点
Node</e><e> next = succ(p)
// 如果p的下一个节点也为空，说明这个队列已经空了
if (next == null) {
// 更新头节点。
updateHead(h, p)
break
}
// 如果下一个元素不为空，则将头节点的下一个节点设置成头节点
p = next
}
return null
}
首先获取头节点的元素，然后判断头节点元素是否为空，如果为空，表示另外一个线程已经进行了一次出队操作将该节点的元素取走，如果不为空，则使用CAS的方式将头节点的引用设置成null，如果CAS成功，则直接返回头节点的元素，如果不成功，表示另外一个线程已经进行了一次出队操作更新了head节点，导致元素发生了变化，需要重新获取头节点。
还是不错的目 录
第一部分：线程并发基础
第1章 概念部分 1
1.1 CPU核心数、线程数 (主流cpu，线程数的大体情况说一下) 1
1.2 CPU时间片轮转机制 2
1.3 什么是进程和什么是线程 4
1.4 进程和线程的比较 5
1.5 什么是并行运行 7
1.6 什么是多并发运行 8
1.7 什么是吞吐量 9
1.8 多并发编程的意义及其好处和注意事项 10
1.9 分布式与并发运算关系 11
1.10 Linux和Window多并发可以采取不的一样机制(apache和tomcat？？) 6
第2章 认识Java里面的Thread 12
2.1 线程的实现三种方法 (先感受一下创建几个多线程方法实例演练)12
2.2 Thread里面的属性和方法 (通过工具看看能不能监控到thread里面的一些属性值)16
2.3 线程的生命周期 19
2.4 什么是守护线程 31
2.5 线程组 33
2.6 当前线程副本ThreadLocal(用意和实际应用场景) 35
2.7 线程异常的处理(单个和组)38
第3章 Thread安全 39
3.0 线程的内存模型
3.1 什么是不安全(写个代码例子多并发带来的一些问题，变量互串，相互影响) 39
3.2 什么是安全(写个代码例子，安全的三种(多实例,加锁,线程安全的集合类)情况，引出锁) 43
3.3 第一种锁：隐式锁，又称线程同步synchronized(举几个例子实际演示一下，及其写法注意，带来的额外开销) 45
3.4 第二种锁：显示锁，Lock；及其与synchronized的区别(ReentrantReadWriteLock) 49
3.5 什么是死锁 53
3.6 看如下代码的锁有用吗 55
3.7 关键字：volatile 57
3.8 原子操作：atomic(atomic包FutureTask, AtomicLong等) 59
3.9 线程同步和锁的原理(有待弄清楚锁的运行机制和原理) 61
3.10 单利模式的写法 63
第4章 线程安全的集合类 64
4.1 java.util.concurrent. ConcurrentMap 64
4.2 java.util.concurrent.ConcurrentHashMap 66
4.3 java.util.concurrent. CopyOnWriteArrayList 68
4.4 java.util.concurrent. CopyOnWriteArraySet 70
4.5 非concurrent下面的线程安全集合类(Hashtable 和 Vector 和StringBuffer) 72
4.6 集合类安全的实现原理剖析 75
第二部分：线程并发晋级之高级部分 75
第5章 多线程之间交互：线程阀
(一句话解释什么叫阀门，最好都能讲到实际使用的例子)75
5.1 线程安全的阻塞队列BlockingQueue (详解一翻java.util.concurrent.ConcurrentLinkedDeque 和java.util.concurrent. ConcurrentLinkedQueue) 76
5.2 同步计数器CountDownLatch 81
5.3 循环障碍CyclicBarrier 84
5.4 信号装置Semaphore 87
5.5 任务机制FutureTask 90
第6章 线程池 115
6.1 什么是线程池 90
6.2 newFixedThreadPool的使用 92
6.3 newCachedThreadPool 的使用 94
6.4 newSingleThreadExecutor的使用(插图，原理) 96
6.5 线程池的好处(未使用的时候的情况，使用后的情况) 98
6.4 认识ExecutorService(ThreadFactory先创建一个线程及其参数的详细讲解，如何自定义线程池) 100
6.5 线程池的原理 106
6.6 线程池在工作中的错误使用 112
第7章 JDK7新增的Fork/Join 115
7.1 什么是Fork/Join 架构 115
7.2 创建实际使用Fork/Join 线程池118
7.3 合并任务的结果 123
7.4 工作原理 126
7.5 异步运行任务 130
7.6 在任务中抛出异常 135
7.7 结束任务 140
7.8 实际应用场景 143
第三部分：实际的使用与监控与拓展
第8章 线程，线程池在Servlet中 150
第9章 Tomcat中线程池如何设置 180
第10章 线程的监控及其日常工作中如何分析 210
linux分析监控方法
java的bin下面监控工具的使用
第11章 线程在Android开发中的体现 250
android的线程讲解
