Java并发编程实战

某个类的行为与其规范完全一致

不包含可变状态

纯函数

独立性

在并发编程中，由于不恰当的执行时序而出现不正确的结果就是竞态条件

比如未加锁锁的懒加载单例，可能导致创建多个实例

包含了一组必须以原子方式执行的操作以确保线程安全性

原子变量类 AtomicLong

Synchronized Block

同步代码块包含两部分：一个作为锁的对象引用，一个作为由这个锁保护的代码块

每个Java对象都可以用作一个实现同步的锁，这些锁被称为内置锁或监视锁

Java的内置锁相当于一中互斥体（或互斥锁）

这种方式又会导致性能问题

内置锁是可重入的

重入的一种实现方法是，为每个锁关联一个获取计数值和一个所有者的线程

当计数值为0时，这个锁就被认为是没有被任何线程持有

当线程请求一个未被持有的锁时，JVM将记下锁的持有者，并且将获取计数值置为1

如果同一个线程再次获取这个锁，计数值将递增，而当线程退出同步代码块时，计数器会相应地递减。

当计数值为0，这个锁将被释放

重入避免了一些死锁的发生

在没有同步的情况下，编译器、处理器以及运行时等可能对操作的执行顺序进行一些
意想不到的调整

可以理解为读到了被其他线程修改前的数据
有点像事务中的脏读

Java内存模型要求，变量的读取操作和写入操作都必须是原子操作，但对于非volatile类型的long和double变量
JVM允许将64位的读操作或写操作分解为两个32位的操作

加锁的含义不仅仅局限于互斥行为，还包括内存可见性。为了确保所有线程都能看到共享变量的最新值。
所有执行读操作或者写操作的线程都必须在同一个锁上同步

问题：如果不是同一把锁呢？

稍弱的同步机制，即volatile变量，用来确保将变量的更新操作通知到其他线程。

当把变量声明为volatile类型后，编译器与运行时都会注意到这个变量是共享的，因此不会将
该变量上的操作与其他内存操作一起重排序。

volatile变量不会被缓存在寄存器或者对其他处理器不可见的地方，因此在读取volatile类型的变量时总会
返回最新写入的值

不建议过度依赖volatile变量提供的可见性

正确示例：比如某个boolean标志位

加锁机制既可以确保可见性又可以确保原子性，而volatile变量只能确保可见性

使对象能够在当前作用域之外的代码中使用

不应该发布的对象被发布

在构造过程中使this引用溢出的一个常见错误是，在构造函数中启动一个线程

如果想在构造函数中注册一个时间监听器或启动线程，那么可以使用一个私有的构造函数
和一个公共的工厂方法，从而避免不正确的构造过程

维护线程封闭性的职责完全由程序实现来承担

脆弱，尽量少用

栈封闭式线程封闭的一种特例

也被称为线程内部使用或者线程局部使用，不要与核心类库中的ThreadLocal混淆

如果局部变量被发布，那么封闭性将被破坏，并导致对象的逸出

维持线程封闭性 的一种更规范方法

这个类能使线程中的某个值与保存值的对象关联起来

ThreadLocal提供了get与set等访问接口或方法，这些方法为每个使用该变量的线程都
存有一份独立的副本，因此get总是返回由当前执行线程在调用set时设置的最新值

ThreadLocal对象通常用于防止对可变的单实例变量或全局变量进行共享
例如：在单线程应用程序中可能会维持一个全局的数据库连接，并在程序启动时初始化这个连接对象，
从而避免在调用每个方法时都要传递一个Connection对象。

当某个频繁执行的操作需要一个临时对象，例如一个缓存区，而同时又希望避免每次执行时都重新分配该
临时对象，就可以使用这项技术

对象创建以后其状态就不能修改

对象的所有域都是final类型

对象是正确创建的（在对象的创建期间，this引用没有逸出）

final 域能确保初始化过程的安全性，从而可以不受限制地访问不可变对象，并在共享这些对象时无须同步

将多个可变变量封装在由volatile修饰的变量内部

这段代码会运行失败。由于存在可见性问题，其他线程看到的Holder对象将处于不一致的状态，即便
    在该对象的构建函数中已经正确地构建了不变性条件。这种不正确的发布导致其他线程看到尚未创建完成的对象

1，除了发布对象的线程外，其他线程可以看到的Holder域是一个失效值
因此将看到一个空引用或之前的旧值

2，线程看到Holer应用的值是最新的，但Holder状态的值却是失效的
某个线程在第一次读取域时得到失效值，而再次读取这个域时会得到一个更新值
这也是抛出AssertionError的原因

即使在发布不可变对象的引用时没有使用同步，也仍然可以安全地访问该对象。
为了维持这种初始化安全性的保证，必须满足不可变性的所有需求：状态不可修改，所有域都是final类型，以及正确的构造过程

在静态初始化函数中初始化一个对象引用

将对象的引用保存到volatile类型的域或者AtomicReferance对象中

将对象的引用保存到某个正确构造对象的final类型域中

将对象的引用保存到一个由锁保护的域中

在没有额外的同步的情况下，任何线程都可以安全地使用被安全发布的事实不可变对象。
即使这个对象没有满足3.5.3的一些条件

对象的发布需求取决于它的可变性

在并发程序中使用和共享对象时，可以使用一些实用的策略，包括

找出构成对象状态的所有变量

找出约束状态变量的不变性条件

建立对象状态的并发访问管理策略

如果在某个操作中包含有基于状态的先验条件，那么这个操作就称为依赖状态的操作

例如列表的删除操作之前要验证非空

就是构成一个对象所有的子集的状态

该模式仅仅是一种编写代码的约定，对于任何一种锁对象，
只要自始至终都使用该锁对象，都可以用来保护对象的状态

例如通过一个私有锁来保护状态

import java.util.Collections;
import java.util.HashSet;
import java.util.Set;

public class PointSet {
    private final Set<Point> points = Collections.synchronizedSet(new HashSet<>());
    
    public void addPoint(Point point) {
        points.add(point);
    }
    
    public boolean containsPoint(Point point) {
        return points.contains(point);
    }
}

上面讲到的都仅仅委托给了单个线程安全的状态变量。我们还可以将线程安全性委托给多个状态变量，
只要这些变量是彼此独立的，即组合而成的类并不会再其包含的多个状态变量上增加任何不变性条件

就是多个变量

比如定义了几个Atomic类型的但是set、get没有保证安全，那么这就是委托失效

所以：volatile变量规则：仅当一个变量参与到包含其他状态变量的不变性条件时，才可以声明为volatile类型

如果一个状态变量是线程安全的，并且没有任何不变性标间来约束它的值，在变量的操作上也
不存在任何不允许的状态转换，那么就可以安全地发布这个变量

客户端加锁机制与扩展类机制有许多共同点，二者都是将派生类的行为与基类耦合在一起。
会破坏同步策略的封装性

当为现有的类添加一个原子操作时，有一种更好的方法：组合

public class MyList<T> implements List<T> {

    private final List<T> list;

    public MyList(List<T> list) {
        this.list = list;
    }

    public synchronized boolean putIfAbsent(T x) {
        // 这个锁是MyList的还是List的，这样就安全了吗
        boolean contains = list.contains(x);
        if (contains) {
            list.add(x);
        }
        return !contains;
    }
}

那些变量声明为volatile类型

那些变量用锁来保护

那些锁锁保护那些变量

那些变量必须是不可变的或者是封闭在线程中的

那些操作必须是原子操作

性能开销

死锁

并发性降低

复合操作的原子性

迭代器的安全性

当它们发现容器在迭代过程中被修改时，就会抛出这个异常。及时失败

如果不希望在迭代期间对容器加锁，那么一种替代方法就是“克隆”容器
并在副本上进行迭代

虽然加锁可以防止迭代器抛出ConcurrentModificationException，
但是你必须要记住所有对共享容器进行迭代的地方都需要加锁

更复杂的是，有些迭代器会隐藏起来
比如字符串的拼接

ConcurrentHashMap并不是将每个方法都在同一个锁上同步并使得每次只有
只能有一个线程访问容器，而是使用一种粒度更细的加锁机制来实现更大程度
的共享，这种机制称为分段锁

弱一致性，像size和isEmpty这样的方法返回的是一个近似值而不是精确值，但他们在并发环境下的用处很小。因此
这些操作的需求被弱化了，以换取对其他操作的性能优化，比如get , put, containsKey和remove

子主题

比如“若没有则添加”，“若相等则移除”，“若相等则替换”等等，在ConcurrentMap接口中声明了，
我们只需要重写即可

问题：ConcurrentMap接口中定义V putIfAbsent(K key, V value); 我implements ConcurrentMap，重写putIfAbsent是用的谁的锁

当您实现 ConcurrentMap 接口时，在重写 putIfAbsent(K key, V value) 方法时，通常会使用内部的锁机制来确保线程安全。ConcurrentMap 接口的实现类通常会使用一种叫做分段锁（segment locking）的方式来实现并发访问控制。

在分段锁的实现中，ConcurrentMap 内部会维护多个小锁（segments），每个小锁负责管理一个较小的数据集。当执行 putIfAbsent 操作时，会先确定应该操作哪个小锁，然后对该小锁进行加锁操作，以确保并发访问时的线程安全性。这样可以降低锁的粒度，提高并发性能。

因此，在您重写 putIfAbsent 方法时，具体的锁机制是由 ConcurrentMap 接口的实现类来处理的，您无需显式地处理锁的细节。只要按照接口规范编写正确的逻辑即可，底层的锁机制会由实现类来确保线程安全。

总之，重写 putIfAbsent 方法时，不需要显式处理锁，而是依赖于 ConcurrentMap 接口实现类内部的锁机制来保证并发访问的线程安全性。

问题：为啥继承Vector扩展方法不好，应为扩展后的方法使用的锁是子类的锁

public class MyVector<K, V> extends Vector<Map.Entry<K, V>> {
// 这个锁是MyVector的    
public synchronized V putIfAbsent(K key, V value) {
        // 加锁确保线程安全
        for (Map.Entry<K, V> entry : this) {
            if (Objects.equals(entry.getKey(), key)) {
                return entry.getValue();
            }
        }
        this.add(new AbstractMap.SimpleEntry<>(key, value));
        return null;
    }
}

用于替代同步List, 在某些情况下它提供了更好的并发性能，并且在迭代期间不需要对容器进行加锁或负责

类似的，CopyOnWriteArraySet的作用是替代同步Set

“写入时复制”容器的线程安全性在于，只要真确发布一个事实不可变对象，那么在访问该对象时就不再需要进一步的同步。
在每次增删改时，都会创建并重新发布一个新的容器副本，从而实现可变性。

对容器进行修改（添加、删除元素）时，不直接在原始数据上进行操作，而是先将原始数据复制一份，在副本上进行修改，最后将修改后的副本替换原始数据。

适用场景

LinkedBlockingQueue和ArrayBlocking-Queue

SynchronousQueue

将多个任务拆分，然后都放到控制流的队列处理

对于可变对象，生产者-消费者这种设计与阻塞队列一起，促进了串行线程封闭，从而将
对象所有权从生产者交付给消费者。

线程封闭对象只能由单个线程拥有，但可以通过安全地发布该对象来“转移”所有权。

在转移所有权后，也只有另一个线程能获得这个对象的访问权限，并且发布对象的线程不会再访问它

这种安全的发布确保了对象状态对于新的所有者来说是可见的，并且由于最初的所有者不会再访问它，
因此对象将被封闭在新的线程中

Java6 增加了两种容器类型 Deque和BlockingDeque

Deque是一个双端队列，实现了在队列头和队列尾的高效插入和移除。
具体实现包括ArrayDeque和LinkedBlockingDeque

双端队列的工作模式

等待IO操作结束

等待获取一个锁

等待从Thread.sleep方法中醒来

等待另一个线程的计算结果

等待IO完成

等待某个锁变成可用

等待外部计算的结束

当某个外部事件发生时，线程被置回RUNNABLE状态，并可以再次被调度执行

一个线程不能强制其他线程停止正在执行的操作而去执行其他的操作

如果线程处于阻塞状态（如调用了 sleep()、wait()、join() 等方法），并且在阻塞期间被中断，
那么线程会抛出 InterruptedException 异常，而不是直接进入阻塞状态码。这意味着线程被中断后，
会从阻塞状态中醒来，并且抛出异常，需要在代码中捕获并处理这个异常。

在其他情况下，比如线程处于运行状态，如果线程被中断，它会收到中断信号，但并不会直接进入阻塞状态，
线程可以继续执行，只是在合适的时机根据中断状态做出相应的处理。

总之，线程的中断并不是直接让线程进入阻塞状态，而是一种通知机制，
线程需要根据中断状态来做出相应的处理，无论线程处于何种状态。

我们可以使用interrupt方法来定制化我们想需求

传递InterruptedException

恢复中断

它们封装了一些状态

这些状态将决定执行同步工具类的线程是继续执行还是等待，此外
还提供了一些方法对状态进行操作，以及另一些用于高效地等待同步
工具类进入预期状态

可以延迟线程的进度直到其到达终止状态

闭锁的作用相当于一扇门：在闭锁到达结束状态之前，这扇门一直是关闭的，
并且没有任何线程能通过，
当到达结束状态时，这扇门会打开并允许所有的线程通过。
当闭锁到达结束状态后，将不会再改变状态，因此这扇门将永远保持打开状态

场景：闭锁可以用来确保某些活动直到其他活动都完成后才继续执行

CountDownLatch是一种灵活的闭锁实现

示例：使用两个闭锁，一个表示起始门，一个表示结束门。
每个线程工作线程首先要做的是在起始门上等待，从而确保所有线程都就绪才开始执行。
而每个线程要做的最后一件事就是将调用结束梦的countDown方法减1，
这能使主线程高效地等待直到所有工作线程都执行完毕，因此可以统计所消耗的时间

FutureTask也可以用作闭锁

FutureTask实现了Future语义，表示一种抽象的可生产结果的计算

FutureTask表示的计算是通过Callable来实现的，相当于一种可生成结果的Runnable，并且可以处于以下3种状态

执行完成 表示计算的所有可能结束方式，包括

当FutureTask进入完成状态后，它会永远停止在这个状态上

Future.get的行为取决于任务的状态。如果任务已完成，那么get会立即返回结果，否则get将阻塞直到
任务进入完成状态，然后返回结果或者抛出异常

FutureTask将计算结果从执行计算的线程传递到获取这个结果的线程，
而FutureTask的规范确保了这种传递过程能实现结果的安全发布

FutureTask在Executor框架中表示异步任务，此外还可以用来表示一些时间较长的计算，
这些计算可以在使用计算结果之前启动

计数信号量用来控制同时访问某个特定资源的操作数量，或者同时执行某个指定操作的数量。

计数信号量还可以用来实现某种资源池，或者对容器施加边界

Semaphore中管理着一组虚拟的许可（permit），许可的初始数量可通过构造函数来指定。
在执行操作时可以首先获得许可（只要还有剩余的许可），并在使用以后释放许可。
如果没有许可，那么acquire将阻塞直到有许可（或者直到被中断或者操作超时）。
release方法将返回一个许可给信号量。

Semaphore可以用于实现资源池，例如数据库连接池

闭锁是一次性对象，一旦进入终止状态，就不能被重置

栅栏（Barrier）类似于闭锁，它能阻塞一组线程直到某个事件发生。

栅栏和闭锁的区别

CyclicBarrier。当线程到达栅栏位置时将调用await方法，这个方法将阻塞直到所有线程都到达栅栏位置

另一种形式是栅栏是Exchanger,  它是一种两方栅栏，各方在栅栏位置上交换数据。
当两方执行不对称的操作时，Exchanger会非常有用。
例如当一个线程向缓冲区写入数据，而另一个线程从缓存区中读取数据。这些线程可以使用Exchanger来汇合

final new HashMap<A,V>

synchronized compute方法

问题：不管是计算线程还是读取线程都要获取锁进行排队

将HashMap替换为ConcurrentHashMap<A,V>

问题：如果某个线程启动了一个开销很大的计算，而其他
线程并不知道这个计算正在进行，那么很可能会重复这个计算

ConcurrentHashMap<A,V>替换为ConcurrentHashMap<A,Future<V>>

如果一个计算还没有启动，那么就创建一个FutureTask, 并注册到Map中，然后启动运算

如果已经启动，那么等待现有计算的结果就可以了

问题：存在两个线程计算出相同值的漏洞

不使用原始的put方法，而是使用putIfAbsent原子方法

串行处理机制通常都无法提供高吞吐率或快速响应性。比如遇到IO

为每个请求创建一个新的线程来提供服务

线程生命周期的开销非常高

资源消耗

稳定性

我们也可以implements Executor，重写execute方法添加我们需要的逻辑

在什么线程中执行任务？

任务按照什么顺序执行（FIFO、LIFO、优先级）？

有多少个任务能并发执行？

在队列中有多少个任务在等待执行？

如果系统由于过载而需要拒绝一些任务，那么应该选择哪一个任务？另外，
如何通知应用程序有任务被拒绝

在执行一个任务之前或之后，应该进行那些动作？

各种执行策略都是一种资源管理工具，最佳策略取决于可用的计算资源以及对服务质量的需求

线程池是与工作队列密切相关的，其中在工作队列中保存了所有等待执行的任务。

工作者线程的任务很简单：从工作队列中获取一个任务，执行任务，然后返回线程池并等待下一个任务

类库提供一个灵活的线程池以及一些有用的默认配置

如果无法正确关闭Executor，那么JVM将无法结束

为了解决执行服务的声明周期问题，Executor扩展了ExecutorService接口，添加
了一些用于生命周期管理的方法

ExecutorService的生命周期有3种状态: 运行、关闭和已终止

ExecutorService在初始创建时处于运行状态。
shutdown方法将执行平缓的关闭过程：不再接受新的任务，同时等待已经提交的任务执行完成---包含那些还未开始执行的任务。
shutdownNow方法将执行粗暴的关闭过程：它将尝试取消所有运行中的任务，并且不再启动队列中尚未开始执行的任务。

在ExecutorService关闭后提交的任务将由“拒绝执行处理器”来处理，它会抛弃任务，或者使得execute方法抛出一个未检查的
RejectedExecutionExcepion。
等所有任务都完成后，ExecutorService将转入终止状态。可以调用awaitTermination来等待ExecutorService到达终止状态，
或者通过调用isTerminated来轮询ExecutorService是否已经终止。
通常在调用awaitTermination之后会立即调用shutdown, 从而产生同步地关闭ExecutorService效果。

Timer类负责管理延迟任务以及周期任务，但是存在一些缺陷

使用ScheduledThreadPoolExecutor来代替它

如果要构建自己的调度任务，那么可以使用DelayQueue，它实现了BlcokingQueue，并未ScheduledThreadPoolExecutor提供调度任务。
DelayQueue管理着一组Delayed对象。每个Delayed对象都有一个相应的延迟时间：在DelayQueue中，只有某个元素逾期后，才能从
DelayQueue中执行take操作。
从DelayQueue中返回的对象将根据他们的延迟时间进行排序。

许多任务实际上都是存在延迟的计算----执行数据库查询，从网络上获取资源，或者计算某个复杂的功能。
对于这个任务，Callable是一种更好的抽象：它任务主入口点（即call）将返回一个值，并可能抛出一个异常。

Runnable和Callable描述的都是抽象的计算任务。这些任务通常是有范围的，即都有一个明确的起始点，
并且最终会结束

Callable需要通过ExecutorService的submit()方法提交执行，返回一个Future对象；而Runnable可以直接通过
Thread的构造函数或者ExecutorService的execute()方法提交执行。

Executor执行的任务有4个生命周期阶段：创建、提交、开始、完成

Future表示一个任务的生命周期，并提供了相应的方法来判断是否已经完成或取消，以及
获取任务的结果和取消任务等。

Future规范中隐含：任务的生命周期只能前进，不能后退

Future的get方法的行为取决于任务的状态（尚未开始、正在运行、已完成）

FutureTask实现了Runnable, 因此可以将它提交给Executor来执行，或者直接调用它的run方法

只有当大量相互独立且同构的任务可以并发进行处理时，才能体现
出将程序的工作负载分配到多个任务中带来的真正的性能提升

如果向Executor提交了一组任务，并且希望在计算完成后获得结果，那么可以保留与每个
任务关联的Future, 然后反复使用get方法，同时将参数timeout指定为0，从而通过轮询来
判断任务时候完成。这种方法虽然可行，但却有些繁琐。更好的处理方式是CompletionService（完成任务）

CompletionService将Executor和BlockingQueue的功能融合在一起。你可以将Callable任务提交给它来执行，
然后使用类似于队列操作的take和poll等方法来获取已完成的结果，而这些结果会在完成时将被封装为Future。

有时候，如果某个任务无法在指定时间内完成，那么将不再不要它的结果，此时可以放弃这个任务

Future.get中支持这种需求：当结果可用时，它将立即返回，如果在指定时限内没有计算出结果，将抛出TimeoutException。
这个时候可以catch捕获，Future.cancel来取消任务，避免资源的浪费

用户请求取消

有时间限制的操作

应用程序事件

错误

关闭

线程中断是一种协作机制，线程可以通过这种机制来通知另一个线程，告诉它在
合适的或者可能的情况下停止当前工作，并转而执行其他的工作。

每个线程都有一个boolean类型的中断状态。当中断线程时，这个线程的中断状态将被设置为true。
在Thread中包含了中断线程以及查询线程中断状态的方法，
interrupt方法能中断目标线程，而isInterrupted方法能返回目标线程的中断状态。
静态的interrupted方法将清除当前线程的中断状态，并返回它之前的值，这也是清除中断状态的唯一方法。

阻塞库方法，例如Thread.sleep和Object.wait等，都会检查线程何时中断，并且在发现中断时提前返回。
它们在响应中断时执行的操作包括：清除中断状态，抛出InterruptedException，表示阻塞操作由于中断而提前结束。
JVM并不能保证阻塞方法检测到中断的速度，但在实际情况下响应速度还是非常快的。

当线程在非阻塞状态下中断时，它的中断状态被设置，然后根据将被取消的操作来检查中断状态以判断发生了中断。
通过这样的方法，中断操作将变得“有黏性”----如果不触发InterruptedException，那么中断状态将一直保持，直到明确地清除中断状态

对中断操作的正确理解是：它并不会真正地中断一个正在运行的线程，而只是发出中断请求，然后由线程在下一个合适的时刻中断自己。
这些时刻也被称为取消点。

Thread中的中断方法

正如任务中应该包含取消策略一样，线程同样应该包含中断策略。
中断策略规定线程如何解释某个中断请求---------当发现中断请求时，应该做那些工作（如果需要的话），
那些工作单元对于中断来说是原子操作，以及以多快的速度来响应中断。

最合理的中断策略是某种形式的线程级取消操作或服务级取消操作：
尽快退出，在必要时进行清理，通知某个所有者该线程已经退出。
此处还可以简历其他的中断策略，例如暂停服务或重新开始服务，但对于那些包含非标准中断策略的线程
或线程池，只能用于能知道这些策略的任务中。

抛出InterruptedException只是作为中断响应。
尽快退出执行流程，并把中断信息传递给调用者，从而使调用栈中的上层代码可以采取进一步的操作。

当检查到中断请求时，任务并不需要放弃所有的操作-------它可以推迟处理中断请求，并直到某个更合适的时刻
因此需要记住中断请求，并在完成当前任务后抛出InterruptedException或表示已收到中断请求。
这项技术能够确保在更新过程中发生中断时，数据结果不会被破坏。

如果除了将nterruptedException传递给调用者外还需要执行其他操作，那么应该在捕获nterruptedException之后恢复中断状态。

处理nterruptedException的两种策略

对于一些不支持取消但仍可以调用可中断阻塞方法的操作，它们必须在循环中调用这些方法，并在发现中断后重新尝试。
通常，可中断的方法会在阻塞或进行重要的工作前首先检查中断，从而尽快地响应中断

在取消过程中可能涉及除了中断状态之外的其他状态。
例如，当一个由ThreadPoolExecutor拥有的工作者线程检测到中断时，它会检查线程池是否正在关闭。如果是，它会在
结束之前执行一些线程池清理工作，否则它可能创建一个新线程将线程池恢复到合理的规模。

ExecutorService.submit将返回一个Future来描述任务。

Future拥有一个cancel方法，该方法带有一个boolean类型的参数mayInterruptIfRunning，表示取消操作是否成功。
这只是表示任务是否能够接受中断，而不是表示任务是否能检测并处理中断。

如果mayInterruptIfRunning为true并且任务当前正在某个线程中运行，那么这个线程能被中断。
如果这个参数为false,那么意味着“若任务还没有启动，就不要运行它”，这种方式应该用于那些不处理中断的任务中。

通过任务的Future来取消它们。

当Future.get抛出InterruptedException或TImeoutException时，如果你知道不再需要结果，那么就可以调用Future.cancel来取消任务。

并非所有的可阻塞方法或者阻塞机制都能响应中断

如果一个线程由于执行同步的Socket I/O 或者等待获得内置锁而阻塞，
那么中断请求只能设置线程的中断状态，除此之外没有其他任何作用。

线程阻塞的原因

当把一个Callable提交给ExecutorService时，submit方法会返回一个Future,
我们可以通过这个Future来取消任务。

newTaskFor是一个工厂方法，它将创建Future来代表任务。

newTaskFor还能返回一个RunnableFuture接口，该接口扩展了Fuutre和Runnable

通过定制表示任务的Future可以改变Future.cancel的行为。
例如，实现日志记录等等。

shutdown 正常关闭

shutdownNow 强制关闭

“毒丸”是指一个放在队列上的对象，其含义是：当得到这个对象时，立即停止

在FIFO（先进先出）队列中，“毒丸”对象将确保消费者在关闭之前首先完成队列中的所有工作，
在提交“毒丸”对象之前提交的所有工作都会被清理，而生产者在提交了“毒丸”对象后，将不会再提交
任何工作

如果某个方法需要处理一批任务，并且当所有任务都处理完成后才返回，那么可以通过
一个私有的Executor来简化服务的生命周期管理，其中该Executor的生命周期是由这个
方法来控制的。

我们无法通过常规方法来找出那些任务已经开始但尚未结束。

在正常关闭中，JVM首先调用所有已注册的关闭钩子（Shutdown Hook）。

关闭钩子应该是线程安全的：它们在访问共享数据时必须使用同步机制，并且小心避免死锁。，
这与其他并发代码的要求相同。而且，关闭钩子不应该对应用程序的状态（例如，其他服务是否已关闭，
或者所有的正常线程是否已经执行完成）或者JVM的关闭原因做出任何假设，因此在编写关闭钩子的代码
必须考虑周全。最后，关闭钩子必须尽快退出，因为它们会延迟JVM的结束时间，而用户可能希望JVM能
尽快终止。

关闭钩子不应该依赖那些可能被应用程序或其他关闭钩子关闭的服务。

有时候，你希望创建一个线程来执行一些辅助工作，但又不希望这个
线程阻碍JVM的关闭。

普通线程与守护线程之间的差异仅在于当线程退出时发生的操作。
当一个线程退出时，JVM会检查其他正在运行的线程，如果这些线程
都是守护线程，那么JVM会正常退出操作。当JVM停止时，所有仍然存在
的守护线程都将被抛弃-------既不会执行finally代码块，也不会执行回卷栈，
而JVM只是直接退出。

如果在守护线程中执行可能包含IO操作的任务，那么将是一种危险的行为。
守护线程最好用于执行“内部”任务，例如周期性地从内存的缓存中移除逾期的数据。

当不再需要内存资源时，可以通过垃圾回收器来回收它们。但对于其他一些资源，
例如文件句柄或套接字句柄，当不再需要它们时，必须显式地交还给操作系统。
为了实现这个功能，垃圾回收器对那些定义了finalize方法的对象会j进行特殊处理：
在回收器释放它们后，调用它们的finalize方法，从而保证一些持久化的资源被释放。

由于终结器可以在某个由JVM管理的线程中运行，因此终结器访问的任何状态都可能被多个线程
访问，这样就必须对其访问操作进行同步。

在大多数情况下，通过使用finally代码块和显式的close方法，能够比使用终结器更好地管理资源。
唯一的例外情况在于：当需要管理对象，并且该对象持有的资源是通过本地方法获得的。
基于这些原因以及其他一些原因，我们要尽量避免编写或使用包含终结器的类。

依赖性任务

使用线程封闭机制的任务

对响应时间敏感的任务

使用ThreadLocal的任务

在线程池中，如果任务依赖于其他任务，那么可能产生死锁。

线程饥饿死锁：只要线程池中的任务需要无限期地等待一些必须由池中其他任务才能提供的资源或条件，
例如某个任务等待另一个任务的返回值或执行结果，那么除非线程池足够大，否则将发生线程饥饿死锁。

执行时间较长的任务不仅会造成线程池堵塞，甚至还会增加执行时间较短任务的服务时间。

有一项技术可以缓解执行时间较长任务造成的影响，即限定任务等待资源的时间，而不要
无限制的等待。

基本大小

最大大小

存活时间

时间单位

BlockingQueue

ThreadFactory

RejectedExecutionHandler

回收空闲线程会产生额外的延迟，因为当需求增加时，
必须创建新的线程来满足需求。

BlockingQueue就是为了保存请求突增的情况。

基本的任务排队方法有3种

当有界队列被填满后，饱和策略开始发挥作用。

ThreadPoolExecutor的饱和策略可以通过调用setRejectedExecutionHandler来修改

当工作队列被填满后，没有预定义的饱和策略来阻塞execute。
然后，可以通过使用Semaphore(信号量)来限制任务的到达率

每当线程池需要创建一个线程时，都是通过线程工厂方法来完成的。

默认的线程工厂方法将创建一个新的、非守护的线程，并且不包含特殊的配置信息。

如果我们要定制呢

在Executors中包含一个unconfigurableExecutorService工厂方法，该方法对一个现有的ExecutorService
进行包装，使其只暴露出ExecutorService的方法，因此不能对它进行配置。
使用这项计算以防止执行策略被修改。

beforeExecute

afterExecute

terminated

好处是多个任务不会的处理过程不会重叠

不利之处在于，如果某个任务的执行时间很长，那么其他任务
必须等到该任务执行结束。

Swing的单线程规则是：Swing中的组件以及模型只能在这个事件分发过程
中进行创建、修改以及查询。

Swing中只有少数方法可以安全地从其他线程中调用，而在
Javadoc中已经很清楚地说明了这些方法的线程安全性。

当某个任务在线程中运行了过长时间还没有结束，用户可能希望取消它。
你可以直接通过线程中断来实现取消操作，但是一种更简单的办法是使用
Future，专门用来管理可取消掉的任务。

如果调用Future的cancle方法，并将参数mayInterruptIfRunning设置为true, 那么这个
Future可以中断正在执行任务的线程。

通过Future来表示一个长时间的任务，可以极大地简化取消操作的实现。

在FutureTask中也有一个done方法同样有助于实现完成通知。
当后台的Callable完成后，将调用down。
通过done方法在事件线程中触发一个完成任务，我们能够构造一个BackgroundTask类，
这个类将提供一个在事件线程中调用onCompletion方法。

BackgroundTask还支持进度标识。compute方法可以调用setProgress方法以数字形式来
指示进度。因而在事件线程中调用onProgress，从而更新用户界面以显示可视化的进度信息。

要想实现BackgroungTask，你只需实现compute，该方法将在后台线程中调用。
也可以改写onCompletion和onProgresss, 这两个方法也会在事件线程中调用。

基于FutureTask构造的BackgroundTask还能简化取消操作。
Compute不会检查线程的中断状态，而是调用Future.isCancelled。

专门用来执行长时间的任务。

例如CopyOnWriteArrayList

是指将一个大的数据结构或任务分解成更小的部分，以便并行处理。

分解数据模型的目的主要有两个方面：

如果所有的线程以固定的顺序来获得锁，那么在程序中就不会出现锁顺序死锁的问题。

转账的例子

在指定锁的顺序时，可以使用System.identityHashCode方法，该方法将返回由Object.hashCode返回的值。
在极少数的情况下，两个对象可能拥有相同的散列值，
为了避免这种情况，可以使用“加时赛”锁，其实就是独立与账号参数以外的锁。

如果是转账，应为账号本来就是唯一的，可以对这两个账号排序，从而不需要使用“加时赛”锁

如果在持有锁时调用某个外部方法，那么将出现活跃性问题。在这个外部方法中可能会获取其他锁（这可能
产生死锁），或者阻塞时间过长，导致其他线程无法及时获得当前被持有的锁。

如果调用某个方法时不需要持有锁，那么这种调用被称为开放调用。

开放调用避免了死锁的产生。但是这个时候需要使同步代码块仅被用于保护那些涉及
共享状态的操作。

在构造一个并发对象时，使得每次只有单线程执行使用了开放调用的代码路径。
在关闭某个服务时，你可能希望所有正在运行的操作执行完成以后，再释放这些
服务占用的资源。
如果在等待操作完成的同时持有该服务的锁，那么将很容易导致死锁，但如果在服务
关闭之前就释放服务的锁，则可能导致其他线程开始新的操作。
解决办法：在将服务的状态更新为“关闭”之前一直持有锁，这样其他想要开始新操作的线程，
包括想关闭该服务的其他线程，会发现服务已经不可用，因此也就不会试图开始新的操作。
然后，你可以等待关闭操作结束，并且知道当开放调用完成后，只有执行关闭操作的线程才能
访问服务的状态。

当它们在相同的资源集合上等待时，也会发生死锁。

如果某些任务需要等待其他任务的结果，那么这些任务往往是产生线程饥饿死锁的主要来源。
有界线程池/资源池与相互依赖的任务不能一起使用。

显式使用Lock类中的定时tryLock功能来代替内置锁机制，可以检测死锁和
从死锁中恢复过来。

当使用内置锁时，只要没有获得锁，就会永远等待下去。
而显式锁则可以指定一个超时期限，在等待超过该时间后tryLock会
返回一个失败信息。我们可以根据这个失败信息定制自己要做的事情。

JVM会通过线程转储来帮助识别死锁的发生。

线程转储包括各个运行中的线程的栈追踪信息，这类似于发生异常时的栈追踪信息。

线程转储还包含加锁信息，例如每个线程持有了那些锁，在那些栈帧中获得这些锁，
以及被阻塞的线程正在等待获取那个锁。

当线程由于无法访问它所需要的资源而不能继续执行时，就发生了“饥饿”。
引发饥饿的最常见资源就是CPU时钟周期。
如果在Java应用程序中对线程的优先级使用不当，或者在持有锁时执行一些
无法结束的结构（例如无限循环，或者无限制地等待某个资源），那么也可能导致
饥饿。

要避免使用线程优先级，因为这会增加平台依赖性，并可能导致活跃性问题。
在大多数并发程序中，都可以使用默认的线程优先级。

如果GUI应用程序中使用了后台线程，那么这种问题是很常见的。

如果某个线程长时间占有一个锁（或许正在对一个大容器进行迭代，并且对
每个元素进行计算密集的处理），而其他想要访问这个容器的线程就必须等待
很长时间。

该问题尽管不会阻塞线程，但也不能继续执行，因为线程将不断重复执行相同的操作，
而且总会失败。

活锁通常发生在处理事务消息的应用程序中：如果不能成功地处理某个消息，那么消息处理
机制就回滚整个事务，并将它重新放到队列的开头。
如果消息处理器在处理某种特定类型的消息时存在错误并导致它失败，那么每当这个消息从
队列中取出并传递到存在错误的处理器时，都会发生事务会馆。
由于这条消息又被放回到队列开头，因此处理器将反复调用，并返回相同的结果。
这种消息也叫毒药消息。

在并发应用程序中，通过等待随机长度的时间和回退可以有效避免活锁的发生。

[用户_97008097]

线程之间的协调（例如加锁、触发信号以及内存同步等）

增加的上下文切换

线程的创建和销毁

线程的调度

更有效地利用现有处理资源

在出现新的处理资源时使程序尽可能地利用这些新资源

应用程序的性能可以采用多个指标来衡量，例如服务时间、延迟时间、吞吐率
、效率、可伸缩性、容量等。
（服务时间、等待时间）用于衡量程序的“运行速度”， 即某个指定的任务单元需要“多快”
才能处理完成。
（生产量、吞吐量）用于程序的“处理能力”，即在计算资源一定的情况喜爱，能完成“多少”工作

可伸缩性：当增加计算资源时（例如CPU、内存、存储容量或IO带宽），程序的吞吐量
或者处理能力相应地增加。

当进行性能调优时，其目的通常是用更小的代价完成相同的工作，例如通过缓存来重用之前的计算
当进行可伸缩性调优时，其目的是设法将问题的计算并行化，从而能利用更多的计算资源来完成更多的工作

避免不成熟的优化。首先使程序正确，然后再提高运行速度-----如果它还运行不够快。

性能决策之前的问题

已测试为基准，不要猜测。

比如synchronizedList封装的LinkedList和ConcurrentLinkedQueue

例如锁分解（将一个锁分解为两个锁）和锁分段（把一个锁分解为多个锁）

如果主线程是唯一的线程，那么它基本上不会被调度出去。另一方面，
如果可运行的线程数大于CPU的数量，那么操作系统最终会将某个正在运行的
线程调度出来，从而使其他线程能够使用CPU。
这将导致一次上下文切换，在这个过程中将保持当前运行线程的执行上下文，
并将调度进来的线程的执行上下文设置为当前上下文。

当线程由于等待某个发生竞争的锁而被阻塞时，JVM通常会将这个线程挂起，
并允许它被交换出去。如果线程频繁的发生阻塞，那么它们将无法使用完成的
调度时间片。

在程序中发生越多的阻塞（包括阻塞的IO, 等待获取发生竞争的锁，或者在条件变量上等待），
与CPU密集型的程序就会发生越多的上下文切换，从而增加调度开销，并因此降低吞吐量。

在大多数通用的处理器中，上下文切换的开销相当于5000~ 10000个时钟周期，也就是几微秒。

同步操作的性能开销包含多个方面。在synchronized和volatile提供的可见性保证中可能会使用一些特殊指令，
即内存栅栏。
内存栅栏可以刷新缓存，是缓存无效，刷新硬件的写缓存，以及停止执行管道。
内存栅栏可能同样会对性能带来间接的影响，因为它将抑制一些编译器优化操作。
在内存栅栏中，大多数操作都是不能被重排序的。

在评估同步操作带来的性能影响时，区分有竞争的同步和无竞争的同步非常重要。
synchronized机制针对无竞争的同步进行了优化（volatile通常是非竞争的），但是非竞争同步
将消耗20~ 250个时钟周期。
虽然无竞争同步开销不为零，但它对应用程序整体性能的影响微乎其微

现代的JVM能通过优化来去掉一些不会发生竞争的锁，从而减少不必要的同步开销。
如果一个锁对象只能由当前线程访问，那么JVM就可以通过优化来去掉这个锁获取操作，
因为另一个线程无法与当前线程在这个锁上发生同步。

不要过度担心非竞争同步带来的开销。这个基本的机制已经非常快了，并且JVM还能
进行额外的优化以进一步降低或消除开销。因此，我们应该将优化的重点放在那些发生
锁竞争的地方。

非竞争的同步可以完全在JVM中进行处理，而竞争的同步可能需要操作
系统的介入，从而增加开销。
当在锁上发生竞争时，竞争失败的线程肯定会阻塞。
JVM在实现阻塞行为时，可以采用自旋等待或者通过操作系统挂起被阻塞的线程。
这两种方式的效率高低，要取决于上下文切换的开销以及在成功获取锁之前需要等待的时间。
如果等待时间较短，则适合采用自旋等待方式，而如果等待时间较长，则适合采用线程挂起方式。
有些JVM将根据对历史等待时间的分析数据在这两者之间进行选择，但是大多数JVM在等待锁时
都只是将线程挂起。

锁的请求频率

每次持有锁的时间

减少锁的持有时间

降低锁的请求频率

使用带有协调机制的独占锁，这些机制允许更高的并发性

尽可能缩短锁的持有时间。
例如可以将一些与锁无关的代码移出同步代码块。
但是同步代码块也不能太小，  一些需要采用原子方式执行的操作
必须包含在一个同步块中。

降低线程请求锁的频率。
通过锁分解和锁分段等技术来实现，在这些技术中将采用相互独立的锁来
保护独立的状态变量，从而改变这些变量在之前由单个锁来保护的情况》
但是，发生死锁的风险也越高。

本来我们只需要一个锁来控制多个变量，但是可以为每个变量上锁，比如去锁A变量，
而不影响B变量的读取。

锁分段：对一组独立对象上的锁进行分解。将共享数据分成多个部分，每个部分都有专门的锁来控制访问

在Java中，如果多个线程同时访问共享的数据，可能会导致数据不一致或者错误的结果。
为了解决这个问题，可以使用锁来控制对共享数据的访问。锁分段就是将共享数据分成
多个部分，每个部分都有专门的锁来控制访问。这样，不同的线程可以同时访问不同部
分的数据，从而提高了并发访问的效率。

举个例子，假设有一个包含多个元素的数组作为共享数据。使用锁分段技术时，可以将
数组分成多个小块，每个小块都有自己的锁。这样，当一个线程需要访问数组的某个部
分时，只需获取该部分的锁，而不会影响其他部分的访问。这样就可以实现更细粒度的
并发控制，提高了并发访问的效率。

锁分段的劣势在于：与采用单个锁来实现独占访问相比，要获取多个锁来实现独占
访问将更加困难并且开销更高。

锁分解和锁分段技术都能提高可伸缩性，因为它们都能使不同的线程在不同的数据（或者
同一个数据的不同部分）上操作，而不会相互干扰。
如果程序采用锁分段记录，那么一定要表现出在锁上的竞争效率高于在锁保护的数据上发生
竞争的频率。

当每个操作请求多个变量时，锁的粒度将很难降低。这是在性能与可伸缩性之间相互制衡
的另一方面，一些常见的优化措施，例如将一些反复计算的结果缓存起来，都会引起一些
“热点域”， 而这些热点域往往会限制可伸缩性。

ConcurrentHashMap中的size将对么个分段进行枚举并将每个分段中的元素数量相加，
而不是维护一个全局计数。

例如使用并发容器，读-写锁、不可变对象以及原子变量。

ReadWriteLock：如果多个读取操作都不会修改共享资源，那么这些读取操作
可以同时访问该共享资源，但在执行写入操作时必须以独占形式来获取锁。

CPU没有充分利用的几点原因

工具：vmstat, mpstat, perfmon

什么事对象池，就是对象重复利用的池子，为了解决缓慢的对象生命周期问题

劣势

通常会采用测试不变性条件的形式，即判断某个类的行为是否与其规范保持一致。
例如，假设有一个链表，在它每次被修改时把其大小缓存下拉，那其中一项安全性性
测试就是比较在缓存中保存的大小值与链表中实际元素的数目是否相等。

包括进展测试和无进展测试两方面，这些都是很难量化的----如何验证某个方法是被阻塞了，而不是运行缓慢？
同样，如何测试某个算法不会发生死锁？要等待多久才能宣告它发生了故障？

与活跃性测试相关的是性能测试

在测试并发的基本属性时，需要引入多个线程。大多数测试框架
并不能很好地支持并发性测试：它们很少会包含相应的工具来创建线程
或监视线程，以确保它们不会意外结束。
如果在某个测试用例创建的辅助线程中发现了一个错误，那么框架通常
无法得知与这个线程相关的是哪一个测试，所以需要通过一些工作将
成功或失败信息传递回主线程，从而才能将相应的信息报告出来。

在测试方法的阻塞行为时，将引入额外的复杂性：当方法被成功阻塞后，
还必须使方法解除阻塞。实现这个功能的一种简单方式就是使用中断----
在一个单独的线程中启动一个阻塞操作，等到线程阻塞后再中断它，然后宣告
阻塞操作成功。当然，这要求阻塞方法通过提前返回或者抛出InterruptedException来响应中断。

在阻塞操作的测试中，我们通常会关注以下方面：

例如对内存的测试，堆分析工具

有一种有用的方法可以提高交替操作的数量，以便能更有效地搜索程序的状态空间：
在访问共享状态的操作中，使用Thead.yield将产生更多的上下文切换。

衡量典型测试用例中的端到端的性能

根据经验值来调整各种不同的限值，例如线程数量、缓存容量等。这些限值可能依赖于
具体平台特性（例如，处理器的类型、处理器的布进级别，CPU的数量或内存大小等），
因此需要动态地进行配置，而我们通常需要合理地选择这些值，从而使程序能够在更多的系统
上良好的运行。

垃圾回收的执行时序是无法预测的，因此在执行测试时，垃圾回收器可能在任何时刻运行。
这就可能导致测试结果不准确。

有两种策略可以防止垃圾回收操作对测试结果产生偏差

防止动态编译对测试结果产生偏差的方式：就是是程序运行足够长的时间（至少数分钟）这样编辑过程以及解释执行
都只是总运行时间的很小一部分。
另一种方法是使代码预先运行一段时间并且不测试这段时间的代码性能，这样在开始计时前代码就已经被完全编译了。

如果N个线程从共享工作队列中获取任务并执行它们，并且这些任务都是计算密集型
的以及运行时间较长（但不会频繁地访问共享数据），那么在这种情况下几乎不存在竞争，
吞吐量仅受限于CPU资源的可用性。
然而，如果任务的生命周期非常短，那么在工作队列上将会存在严重的竞争，此时的吞吐量
将受限于同步的开销。

例如开源的FindBugs

比如一些检查器

AOP

可定时的与可轮询的锁获取模式是由tryLock方法实现的，与无条件的锁获取模式相比，
它具有更完善的错误恢复机制。

在内置锁中，死锁是一个严重的问题，恢复程序的唯一方法是重新启动程序，
而防止死锁的唯一方法就是在构造程序时避免出现不一致的锁顺序。
可定时的与可轮询的锁提供了另一种选择：避免死锁的发生。

如果不能获得所有需要的锁，那么可以使用可定时的或可轮询的锁获取方式，从而
使你重新获得控制权，它会释放已经获得的锁，然后重新尝试获取所有的锁（或者至少
会将这个失败记录到日志，并采取其他措施）

在实现具有事件限制的操作时，定时锁同样非常有用。
当在带有事件限制的操作中调佣了一个阻塞方法时，它能根据剩余时间来提供一个时限。
如果操作不能在指定的时间内给出结果，那么就会使程序提前结束。
而内置锁却很难实现这样的操作。

场景：在使用ReentrantLock的定时锁时，时间到了我先unlock,然后抛出异常让事务回滚，

可中断的锁获取操作指的是当一个线程在等待获取锁的过程中，可以被其他线程中断，
即可响应中断请求而放弃获取锁的操作。

在ReentrantLock中，通过lockInterruptibly()方法来实现可中断的锁获取操作。当一个线
程调用lockInterruptibly()方法尝试获取锁时，如果其他线程中断了该线程，那么该线程会
抛出InterruptedException异常，从而中断获取锁的操作。

这种可中断的锁获取操作可以帮助避免线程因为获取锁而被长时间阻塞，提高了程序的健
壮性和响应性。同时，通过使用ReentrantLock的可中断特性，我们可以更加灵活地控制线
程的行为，有效地处理线程之间的竞争关系。

在内置锁中，锁的获取和释放等操作都是基于代码块的----释放锁的操作总是与获取锁的操作
处于同一个代码块，而不考虑控制权如何退出该代码块。

"非块结构的加锁"可能是指在使用 ReentrantLock 时，并不是在传统的 synchronized 块中进行加锁操作。这意味着可以在方法的任意位置调用 ReentrantLock 的 lock() 方法来获取锁和释放锁。
这个lock还能传递到下一个方法，通过下一个方法unlock。

释放优先。
当一个写入操作释放写入锁时，并且队列中同时存在读线程和写线程，
那么应该优先选择读线程，写线程，还是最先发出请求的线程？

读线程插队。
如果锁是由读线程持有，但有写线程正在等待，那么新到达的读线程能够立即获得访问权，
还是应该在写线程后面等待？如果运行读线程插队到写线程之前，那么将提供并发性，
但却可能造成写线程发生饥饿问题。

重入性。
读取锁和写入锁是否是可重入的？

降级。
如果一个线程持有写入锁，那么它能否在不释放该锁的情况下获得读取锁？
这可能会使得写入锁被“降级”为读取锁，同时不允许其他写线程修改被保护的资源。

升级。
读取锁能否优先于其他正在等待的读现场和写线程而升级为一个写入锁？
在大多数的读-写锁实现中并不支持升级，因为如果没有显式的升级操作，
那么很容易造成死锁。

调用者必须自行处理前提条件失败的情况。

如果缓存为空，那么take将休眠并直到另一个线程在缓存中放入一些数据；
如果缓存是满的，那么put将休眠并直到另一个线程从缓存中移除一些数据。

它使的一组线程（称之为等待线程集合）能够通过某种方式来等待特定的条件变为真。
传统队列的元素是一个个数据，而与之不同的是，条件队列中的元素是一个个正在
等待相关条件的线程。

正如每个Java对象都可以作为一个锁，每个对象同样可以作为一个条件队列，
并且Object中的wait、notify、notifyAll方法就构成了内部条件队列的API。

要想正确地使用条件队列，关键是找出对象在那个条件谓词上等待。

条件谓词是使某个操作成为状态依赖操作的前提条件。
在有界缓存中，只有当缓存不为空时，take方法才能执行，否则必须等待。
对take方法来说，它的条件谓词是“缓存不满”。
条件谓词是由类中各个状态变量构成的表达式。

在条件等待中存在一种重要的三元关系，包括加锁、wait方法和一个条件谓词

每一次wait调用都会隐式地与特定的条件谓词关联起来。但调用某个特定条件谓词
的wait时，调用者必须已经持有与条件队列相关的锁，并且这个锁必须保护着构成
条件谓词的状态变量。

当使用条件等待时（例如Object.wait 或Condition.await）

丢失的信号是指：线程必须等待一个已经为真的条件，但在开始等待之前
没有检查条件谓词。
现在，线程将等待一个已经发生过的事件。

每当在等待一个条件时，一定要确保在条件谓词变为真时通过某种方式发出通知。

在条件队列API中有两个发出通知的方法，即notify和notifyAll。
无论调用哪一个，都必须持有与条件队列对象相关联的锁。

在调用notify时，JVM会从这个条件队列上等待的多个线程中选择一个来唤醒，
而调用notifyAll则会唤醒所有在这个条件队列上等待的线程。

由于在调用notify或notifyAll时必须持有条件队列对象的锁，而如果这些等待
中线程此时不能重新获得锁，那么无法从wait返回，因此发出通知的线程应该
尽快地释放锁，从而确保正在等待的线程尽可能快地解除阻塞。

只有同时满足以下两个条件，才能用单一的notify而不是notifyAll

闭锁的缺陷：
按照这种方式构造的阀门在打开后无法重新关闭。

当增加一个新的状态依赖操作时，可能需要对多条修改对象的代码路径进行改动，
才能正确地执行通知。

在使用条件通知或单次通知时，一些约束条件使得子类化过程变得更加复杂。
要想支持子类化，那么在设计类时需要保证：如果在实施子类化时违背了条件
通知或单次通知的某个需求，那么在子类中可以增加合适的通知机制类代表基类。

对于状态依赖的类，要么将其等待和通知等协议完全向子类公开，
要么完全阻止子类参与到等待和通知等过程中。

通常，我们应该把条件队列封装起来，因而除了使用条件队列的类，
就不能在其他地方访问它。否则，调用者会自以为理解了在等待和通知
上使用的协议，并采用一种违背设计的方式来使用条件队列。

条件队列

入口协议就是该操作的条件谓词。
出口协议则包括，检查被该操作修改的所有状态变量，并确认它们
是否使某个其他的条件谓词变为真，如果是，则通知相关的条件队列。

ReentrantLock只支持独占方式的获取操作，因此它实现了tryAcquire、tryRelease和
isHeldExclusively。
ReentrantLock将同步状态用于保存锁获取操作的次数，并且还维护一个owner变量来
保存当前所有者线程的标识符，只有在当前线程刚刚获取到锁，或者正要释放锁的时候，
才会修改这个变量。
在tryRelease中检查owner域，从而确保当前线程在执行unlock操作之前已经获取了锁：
在tryAcquire中将使用这个域来区分获取操作是重入的还是竞争的。

当一个线程尝试获取锁时，tryAcquire将首先检查锁的状态。
如果锁未被持有，那么它将尝试更新锁的状态标识锁已经被持有。
由于状态可能在检查后被立即修改，因此tryAcquire使用compareAndSetState来原子地
更新状态，表示这个锁已经被占有，并确保状态在最后一次检查以后就再没有被修改过。
如果锁状态表明它已经被持有，并且如果当前线程是锁的持有者，那么获取计数会递增，
如果当前线程不是锁的拥有者，那么获取操作将失败。

Semaphore将AQS的同步状态用于保存当前可用许可的数量。tryAcquireShared方法
首先计算剩余许可的数量，如果没有足够的许可，那么会返回一个值表示获取操作失败。
如果还有剩余的许可，那么tryAcquireShared会通过compareAndSetState以原子方式来降低
许可的计数。

如果这个操作成功（这意味着许可的计数自从上一次读取后就没有被修改过），那么将返回一个值
表示获取操作成功。
在返回值中还包含了表示其他共享获取操作能否成功的信息，如果成功，那么其他等待的线程同样
会解除阻塞。

CountDownLatch使用AQS的方式与Semaphore很相似：在同步状态中保存的是当前的计数值。
countDown方法调用release， 从而导致计数值递减，并且当计数值为零时，解除所有等待线程
的阻塞。await调用acquire，当计数器为零时，acquire将立即返回，否则将阻塞。

初看上去，FutureTask甚至不像一个同步器，但Future.get的语义非常类似于闭锁
的语义------如果发生了某个事件（由FutureTask表示的任务执行完成或取消），那么
线程就可以恢复执行，否则这些线程将停留在队列中并直到该事件发生。

在FutureTask中，AQS同步状态被用来保存任务的状态，例如，正在运行、已完成
或已取消。FutureTask还维护一些额外的状态变量，用来保存计算结果或者抛出的异常。
此外，它还维护了一个引用，指向正在执行计算任务的线程（如果它当前处于运行状态），
因而如果任务取消，该线程就会中断。

ReadWriteLock接口表示存在两个锁：一个读取锁和一个写入锁，但在基于AQS实现的
ReentrantReadWriteLock中，单个AQS子类将同时管理读取加锁和写入加锁。

ReentrantReadWriteLock使用了一个16位的状态来表示写入锁的计数，并且使用了另一个
16位的状态来表示读取锁的计数。

在读取锁上的操作将使用共享的获取方法与释放方法，在写入锁上的操作将使用独占的
获取方法与释放方法。

AQS内部维护一个等待线程队列，其中记录了某个线程请求的是独占访问还是共享访问。

在ReentrantReadWriteLock中，当锁可用时，如果位于队列头部的线程执行写入操作，
那么线程会得到这个锁，如果位于队列头部的线程执行读取访问，那么队列中在第一个写入
线程之前的所有线程都将获得这个锁。

在大多数处理器架构中采用的方法是实现一个比较并交换（CAS）指令。
有些处理器中，采用一对指令来实现相同的功能：关联加载和条件存储。

CAS是一项乐观的技术，它希望能成功地执行更新操作，并且如果有另一个线程
在最近一次检查后更新了该变量，那么CAS能检测到这个错误。

当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量
的值，而其他线程都将失败。然后，失败的线程并不会被挂起（这与获取锁的情况不同：当
获取失败时，线程将被挂起），而是被告知在这次竞争中失败，并可以再次尝试。

由于一个线程在竞争CAS时失败不会阻塞，因此它可以决定是否重新尝试，或者执行一些恢复操作，
也或者不执行任何操作。这种灵活性就大大减少了与锁相关的活跃性风险。

初看起来，基于CAS的计数器似乎比基于锁的计数器在性能上更差一些，因为它需要
执行更多的操作和更复杂的控制流，并且还依赖看似复杂的CAS操作。
但实际上，当竞争程度不高时，基于CAS的计数器在性能上远远超过了基于锁的计数器，
而在没有竞争时甚至更好。

一个很管用的经验法则是：
在大多数处理器上，在无竞争的锁获取和释放的“快速代码路径”上的开销，
大约是CAS开销的两倍。

在Java5.0之前，如果不编写明确的代码，那么就无法执行CAS。

在Java5.0引入了底层的支持，在int、long和对象引用等类型上都公开了
CAS操作，并且JVM把它们编程为底层硬件提供的最有效方法。

在支持CAS的平台上，运行时把它们编译为相应的（多条）机器指令。

在最坏的情况下，如果不支持CAS指令，那么JVM将使用自旋锁。

在原子变量类（例如Atomicxxx）中使用了这些底层的JVM支持为数字类型和引用
类型提供一种高效的CAS操作，而在java.util.concurrent中的大多数类在实现时则直接
或间接地使用了这些原子变量类。

由于有一个不变性条件限制了两个数值，并且它们无法在同时
更新时还维持该不变性条件，因此如果在数值范围类中使用
volatile引用或者多个原子整数，那么将出现不安全的“先检查再
运行”操作序列。

在中低程度的竞争下，原子变量能提供更高的可伸缩性。

在高强度的竞争下，锁能够更有效地避免竞争。

创建非阻塞算法的关键在于，找出如何将原子修改的范围
缩小到单个变量上，同时还要维护数据的一致性。

在链式容器类（例如队列中）中，有时候无须将状态转换操作表示为对节点链接的修改，
也无须使用AtomicReference来表示每个必须采用原子操作来更新的链接。

CAS的基本使用模式：在更新某个值时存在不确定性，以及在更新失败时重新尝试。

链表队列比栈更为复杂，因为它必须支持对头节点和尾节点的快速访问。

引入“哨兵节点”或“哑节点”来表示一个中间状态，如果新线程发现是中间状态则等待。

原子的域更新器（AtomicFieldUpdater）是 Java 并发包中提供的一个工具类，
用于对指定类的指定 volatile 字段进行原子更新操作。通常情况下，我们无法
直接对某个类的 volatile 字段进行原子性操作，而原子的域更新器提供了一种
机制来实现对这些字段的原子性更新。

适用场景

注意点

解决方案：
不是更新某个引用的值，而是更新两个值，包括一个引用和一个版本号。

AtomicStampedReference（以及AtomicMarkableReference）支持在两个变量上执行原子的条件更新。

AtomicStampedReference将更新一个“对象-引用” 二元组，通过在引用上加上“版本号”，从而避免ABA问题。

类似地，AtomicMarkableReference将更新一个“对象引用-布尔值”二元组，在某些算法中
将通过这种二元组使节点保存在链表中同时又将其标记为“已删除的节点”。

在编译器中生成的指令顺序，可以与源代码中的顺序不同，
此外编辑器还会把变量保存在寄存器而不是内存中

处理器可以采用乱序或并行等方式来执行指令

缓存可能会改变将写入变量提交到主内存的次序

保存在处理器本地缓存中的值，对于其他处理器是不可见的。

在共享内存的多处理器体系架构中，每个处理都拥有自己的缓存，
并且定期地与主内存进行协调。

在不同的处理器架构中提供了不同级别的缓存一致性，其中一部分
只提供最小的保证，即允许不同的处理器在任意时刻从同一个存储
位置上看到不同的值。

要想确保每个处理器都能在任意时刻知道其他处理器正在进行的工作，
将需要非常大的开销。
在大多数时间里，这种信息是不必要的，因此处理器会适当放宽存储一致性
保存，以换取性能的提升。

在架构定义的内存模型中将告诉应用程序可以从内存系统中获得怎么的保证，
此外还定义了一些特殊的指令（称为内存栅栏或栅栏），当需要共享数据时，
这些指令就能实现额外的存储协调保证。

各种操作延迟或者看似乱序执行的不同原因，都可以归为重排序。

内存级的重排序会使程序的行为变得不可预测。

同步将限制编译器、运行时和硬件对内存操作重排序的方式，
从而在实施重排序时不会破坏JMM提供的可见性保证，

Java内存模型是通过各种操作定义的，包括对变量的读/写操作，监视器
的加锁和释放操作，以及线程的启动和合并操作。

JMM为程序中所有的操作定义了一个偏序关系，称之为Happens-Before。
要想保证执行操作B的线程看到操作A的结果（无论A和B是否在同一个线程
中执行），那么在A和B之间必须满足Happens-Before关系。
如果两个操作之间缺乏Happens-Before关系，那么JVM可以对它们任意地
重排序。

当一个变量被多个线程读取并且至少被一个线程写入时，如果在读操作和写
操作之间没有依照Happens-Before来排序，那么就会产生数据竞争问题。
在正确同步的程序中不存在数据竞争，并会表现出串行一致性，这意味着程序
中的所有操作都会按照一种固定的和全局的顺序执行。

Happens-Before的规则包括：

由于Happens-Before的排序功能很强大，因此有时候可以“借助”现有同步机制的可行性属性。
这需要将Happens-Before的程序顺序规则与其他某个顺序规则（通常是监视器锁规则或者volatile
变量规则）结合起来，从而对某个未被锁保护的变量的访问操作进行排序。

在类库中提供的Happens-Before排序包括:

当缺少Happens-Before关系时，就可能出现重排序问题，这就解释了
为什么在没有充分同步的情况下发布一个对象会导致另一个线程看到
一个只被部分构造的对象。

在初始化一个新的对象时需要写入多个变量，即新对象中的各个域。
同样，在发布一个引用时也需要写入一个变量，即新对象的引用。

如果无法确保发布共享引用的操作在另一个线程加载该共享引用
之前执行，那么对新对象引用的写入操作将与对象中各个域的写入
操作重排序。
在这种情况下，另一个线程可能看到对象引用的最新值，但同时也
将看到对象的某些或全部状态中包含的是无效值，即一个被部分构造
对象。

除了不可变对象以外，使用被另一个线程初始化的对象通常都是不安全的，
除非对象的发布操作是在使用该对象的线程开始使用之前执行。

第三章介绍的安全发布常用模式可以确保被发布对象对于其他线程是可见的，
因为它们保证发布对象的操作将在使用对象的线程开始使用该对象的引用之前执行。

事实上，Happens-Before比安全发布提供了更强可见性与顺序保证。

既然JMM已经提供了这种更强大的Happens-Before关系，那么为什么还要介绍
@GuardedBy和安全发布呢？
与内存写入操作的可见性相比，从转移对象的所有权以及对象公布等角度来看，
它们更符合大多数的程序设计。
Happens-Before排序是在内存访问级别上操作的，它是一种“并发级汇编语言”，
而安全发布的运行级别更接近程序设计。

有时候，我们需要推迟一些高开销的对象初始化操作，并且只有当使用
这些对象时才进行初始化。

在初始器中采用了特殊的方式来处理静态域（或者在静态代码块中初始化的值），
并提供了额外的线程安全性保证。
静态初始化是由JVM在类的初始化阶段执行，即在类被加载后并且被线程使用之前。
由于JVM将在初始化期间获得一个锁，并且每个线程都至少获取一次这个锁以确保
这个类已经加载，因此在静态初始化期间，内存写入操作将自动对所有线程可见。

无论是在在构造期间还是被引用时，静态初始化的对象都不需要显式的同步。
然后，这个规则仅适用于在构造时的状态，如果对象是可变的，那么在读线程
和写线程之间仍然需要通过同步来确保随后的修改操作是可见的，以及避免
数据破坏。

简称：DCL

DCL的真正问题在于：当在没有同步的情况下读取一个共享对象时，可能发生
的最糟糕事情只是看到一个失效值（在这种情况下是一个空值），此时DCL方法
将通过在持有锁的情况下再次尝试来避免这种风险。
然而，实际情况远比这种情况糟糕------线程可能看到引用的当前值，但对象的状态值
却是失效的，这意味着线程可以看到对象处于无效或错误的状态。

在JMM的后续版本（Java5.0以及更高的版本）中，使用volatile修饰变量，那么就
能启用DCL，并且这种方式对性能的影响很小，y因为volatile变量读取操作的性能
通常只是略高于非volatile变量读取操作的性能。

DCL这种使用方法已经被广泛废弃-----促使该模式出现的驱动力（无竞争同步的执行速度很慢，
已经JVM启动时很慢）已经不复存在，因而它不是一种高效的优化措施。
延迟初始化占位符模式能带来同样的优势，并且更容易理解。