软件开发与架构领域 -体系化知识分享

在前面的篇章中，我们详细分析了AQS，并提到了里面一个关键数据结构：所有阻塞线程组成的一个等待队列，这个队列是用单向无锁链表实现的。今天所讲的ConcurrentLinkedQueue，其实现和AQS中的无锁队列基本一样。所以，如果你深刻理解了AQS，ConcurrentLinkedQueue也就知道了。出于内容的完整性，在此还是列一下其源码：public class ConcurrentLinke

说到happen before，很多人都知道。但因为其理论的抽象，以及在语义上的微妙，使得对happen before的理解，往往陷入“隔靴搔痒“的境地。本文试图宏观性、多角度的来分析围绕happen before的诸多问题，从而搞清楚我们为什么需要happen before?-可见性 -重排序 -happen before -共享存储模型 vs. 消息模型可见性说到可见性，很多人立马会想到v

在前面分析ReentrantLock/ReentrantReadWriteLock的时候，我们已经对AQS进行过分析。在初步了解了AQS之后，本篇试图对其进行一个更为系统性的分析。因为AQS是为整个同步框架的基石，不光是锁，很多其他同步组件，比如Semaphore, CountDownLatch，也都是建立在AQS之上。 -AQS–同步框架的基石 -AQS的3个核心技术原理 –AQS源码解析

在JUC包中，线程池部分本身有很多组件，可以说是前面所分析的各种技术的一个综合应用。从本文开始，将综合前面的知识，逐个分析线程池的各个组件。 -Executor/Executors -ThreadPoolExecutor使用介绍 -ThreadPoolExecutor实现原理 –ThreadPoolExecutor的中断与优雅关闭 shutdown + awaitTermination –

在前面分析工具类Executors的时候，提到了CachedThreadPool：其线程数会无限增大，每来一个新请求，就会new一个Thread，其maxPoolSize = Integer.MAX。 其构造函数如下：public static ExecutorService newCachedThreadPool() { return new ThreadPoolExecutor

–ConcurrentHashMap的弱一致性 –SynchronousQueue的弱一致性 –Exchanger的弱一致性 –Linux内核无锁队列的弱一致性 –总结经过前面一系列的源码分析，我们基本覆盖了JUC包的所有组件。在这诸多组件中，我们总是不断看到一个如影随行的东西：CAS。相当锁来讲，它的原子粒度更小，只是作用在一个基本变量上面（比如一个Integer, Long, 或者Ref

DelayQueueScheduledThreadPoolExecutor

ConcurrentHashMap的源码，从JDK1.6到JDK1.7, 经历了不少变化。在JDK1.7中，好几个地方使用了sun.misc.Unsafe里面的函数，比如UNSAFE.putOrderedObject, UNSAFE.getObject..。对于这些函数的原理，笔者也不甚理解。为此，本文的讨论只针对JDK1.6。 -锁分离 -读不加锁，锁加锁 -弱一致性, happen b

在前面JUC源码分析和Disruptor分析序列中，我们已经反复讨论了锁与无锁的问题。众所周知，在多线程程序中，锁是性能杀手。因此“锁优化”一直是多线程中被频繁探讨的一个问题。本文将从“锁优化”这个应用层面，把前面的诸多东西串起来，探讨一下锁优化的一系列策略。策略1：业务和设计层面 – 单线程或去共享资源我们知道，至所以要加锁，是因为多线程 + 共享资源。如果我们可以根据具体业务场景，或者从顶层设

在前面的源码分析中，很多地方用到了Interrupt，在此，对Interrupt做一个深刻总结。一、“中断“这个词有误区，它并不是真的中断一个线程，准备说，应该叫做“中断轻量级阻塞”。什么叫“轻量级阻塞”呢？ 就是调用以下这几个函数，所造成的线程阻塞。此时线程是处于Waiting状态，会响应t.interrupt。响应方式，前4个，是直接抛出InterruptException异常，最后1个，是

说到锁，想必很多人就会被如下的各种专业名词绕晕了。本文试图厘清关于锁的各种概念，从而对锁有一个全面而深入的理解。–自旋锁/阻塞锁 –独占锁（排它锁）/共享锁（读写锁） –公平锁/非公平锁 –偏向锁/非偏向锁 –可重入锁 –悲观锁/乐观锁 –ReentrantLock源码分析 –AbstractQueuedSynchronized（队列同步器） –源码分析 –ReentrantRead

-volatile应用1 – 内存可见性 – JMM内存模型 -volatile应用2 – 原子性 -volatile应用3 – 构造函数逸出/DCL问题(Double Checking Locking) -final应用1 – 避免构造函数重排序 -final应用2 – CopyOnWrite -atomic数组/volatile数组/final数组/ -指令重排序，happen be

在前面的篇章中，讲解了ReentrantLock + Condition，并讲述了2者结合的一个典型应用：ArrayBlockingQueue/LinkedBlockingQueue。今天讲述2者结合的另一个典型应用：CyclicBarrier。CyclicBarrier的概念要介绍CyclicBarrier这个概念，可以从下面这个比喻开始：一个小公司的所有人周六要出去团建，大家提前商定好周六早上

关于Runnable，我们都已经很熟悉了。在上一篇，我们也分析了ThreadPoolExecutor用来执行任务的接口execute，如下所示：public interface Runnable { public abstract void run();}public void execute(Runnable command) { 。。。 }这里的execute(..)是没有返回值

上一篇所讲的SynchronousQueue，是2个线程之间单向的数据传输，一个put，一个take。 而今天所讲的Exchange，顾明思义，是双向的数据传输，2个线程在一个同步点，交换数据。其使用方式，大致如下：Exchange<String> exchange = new Exchange<String>(); //建1个多个线程共用的exchange对象//把exchange对象，传给4个

-为什么是SkipList，不是TreeMap的红黑树? -无锁链表的精髓 -ConcurrentSkipListMap -ConcurrentSkipListSet为什么是SkipList?大家都知道，在Java集合类中，有一个TreeMap，相对于HashMap，它的一个最大特点是：key是有序的。TreeMap的内部是用红黑树实现的。同HashMap一样，它也是非线程安全的。然后在JUC

JDK 1.7 提供了一个并行计算的框架，本文就来分析一下它在使用和实现原理上，和ThreadPool有什么区别。何为Fork/Join？我们在大学算法课本上，学过的一种基本算法就是：分治。其基本思路就是：把一个大的任务分成若干个子任务，这些子任务分别计算，最后再Merge出最终结果。这个过程通常都会用到递归。而Fork/Join其实就是一种利用多线程来实现“分治算法”的并行框架。另外一方面，可以把

乐观锁思想乐观锁的几种具体实现Java CAS原子操作/AtomicInteger实现ABA问题/AtomicStampedReference实现Mysql 乐观锁实现Mysql MVCC总结乐观锁思想问题的提出： 当多个线程或客户端并发修改同1份数据时，不加锁，如何实现互斥访问？乐观锁基本思路： 给数据本身加一个版本号字段，读取和写入时都不加锁。数据读出来的时候，此时版本号

上1篇讲述了Java并发编程的第1个基本思想–CAS/乐观锁，这1篇接着讲述并发编程的第2个基本思想：CopyOnWrite - CopyOnWrite基本思想 - CopyOnWriteArrayList - CopyOnWriteArraySet - AtomicReference的一个应用 - 总结CopyOnWrite基本思想 CopyOnWrite, 顾名思义

-await/signal/signalAll与wait/notify/notifyAll区别 -Condition源码分析 -各种BlockingQueue源码分析await,signal,signalAll以下代码，分别展示了wait/notify, 和Condition的await/signal的用法Object o = new Object();synchronized(o) /