Java多线程编程实战指南（核心篇）读书笔记（三）

（尊重劳动成果，转载请注明出处：http://blog.csdn.net/qq_25827845/article/details/76686044冷血之心的博客）

博主准备恶补一番Java高并发编程相关知识，接下来将阅读该书，并且进行比较详细的总结，好记性不如烂笔头，加油。

Java多线程编程实战指南（核心篇）读书笔记（三），主要记录该书第五章和第六章的基本概念等知识，后续部分将会持续更新哦~欢迎关注本博客。

目录：

Java多线程编程实战指南（核心篇）读书笔记（一）

Java多线程编程实战指南（核心篇）读书笔记（二）

Java多线程编程实战指南（核心篇）读书笔记（三）

Java多线程编程实战指南（核心篇）读书笔记（四）

Java多线程编程实战指南（核心篇）读书笔记（五）

1. 线程间协作
   1. 等待与通知：wait/notify
      1. 等待：一个线程因其执行目标动作所需的保护条件未满足而被暂停的过程
      2. 通知：一个线程更新了系统的状态，使得其他线程所需的保护条件得以满足的时候唤醒那些被暂停的线程的过程。
      3. 为什么wait方法必须放在临界区中使用？
         1. 由于一个线程只有在持有一个对象的内部锁的情况下才能够调用该对象的wait方法
      4. 概念：
         1. 设obj是Java中任意一个类的实例，因执行obj.wait( )而被暂停的线程就称为对象obj上的等待线程，一个对象可以存在多个等待线程。
      5. 注意：调用obj.wait（）方法之后，该方法并没有返回，只不过是将线程暂停了而已；当我们在后边调用obj.notify（）方法之后，被唤醒的任意一个线程在其再次持有obj对应的内部锁的情况下继续执行obj.wait（）方法中剩余的指令，直到wait方法返回。
      6. obj.wait（）暂停当前线程时释放的锁只是与该wait方法所属对象的内部锁。当前线程所持有的其它内部锁。显示锁不会被释放
      7. 这是一种非公平的调度方式，等待线程和通知线程是同步在同一对象之上的两种线程
      8. wait/notify的开销与问题：
         1. 过早唤醒问题
         2. 信号丢失问题
            1. 等待线程错过了一个本来发送给它的信号，导致等待线程一直处于等待状态
         3. 欺骗性唤醒问题
         4. 上下文切换 
      9. 选择：
         1. notify可能导致信号丢失的问题
         2. notifyAll会把不需要唤醒的等待线程都唤醒了，但是正确性有保障
         3. 使用notify代替notifyAll的条件：
            1. 一次通知仅需要唤醒至多一个线程
            2. 相应对象上的所有等待线程都是同质等待线程
      10. Thread.join( )
          1. 使用wait和notify配合实现
          2. 当前线程调用，则其它线程等待当前线程执行完毕
   2. Java条件变量：Condition
      1. Condition接口可作为wait/notify的替代品来实现等待和通知，它为解决过早唤醒问题提供了支持，对应方法包括await、singal和singalAll方法
      2. Lock.newCondition( )的返回值就是一个Condition实例
      3. Condition.await/singal也要求执行线程持有创建该Condition实例的显示锁，每个Condition实例内部都维护了一个用于存储等待线程的队列（也就是为什么可以避免过早唤醒的原因）
   3. 倒计时协调器：CountDownLatch
      1. 一个线程可能只需要等待其他线程执行的特定操作结束即可，而不必等待这些线程终止，可以使用CountDownLatch实现
      2. CountDownLatch可以用来实现一个（或者多个）线程等待其他线程完成一组特定的操作之后才继续运行
      3. 该协调器内部维护一个计数器，CountDownLatch.countDown（）每被执行一次都会使计数器值减少1.
      4. CountDownLatch.await( )，当计数器不为0时，该方法的调用将会导致执行线程被暂停，这些线程就叫做该CountDownLatch上的等待线程。
      5. CountDownLatch.countDown（）相当于一个通知方法，当计数器值达到0时，唤醒所有等待线程。
      6. 当然对应还有CountDownLatch.await( long , TimeUnit)方法
      7. CountDownLatch的使用是一次性的
   4. 栅栏（CyclicBarrier）
      1. 有时候多个线程可能需要相互等待对方执行到代码中的某个地方（集合点），这时这些线程才能够继续执行。
      2. 使用CyclicBarrier实现等待的线程被称为参与方（Party）。参与方只需要执行CyclicBarrier.await（）就可以实现等待
      3. 该栅栏维护了一个显示锁，可以识别出最后一个参与方，当最后一个参与方调用await（）方法时，前面等待的参与方都会被唤醒，并且该最后一个参与方也不会被暂停。
      4. 内部实现：
         1. 维护了一个计数器变量count = 参与方的个数
         2. 调用await方法可以使得count-1；
         3. 当判断到是最后一个参与方时，调用singalAll唤醒所有线程
      5. 应用场景：
         1. 使迭代算法并发化
         2. 在测试代码中模拟高并发
            1. CyclicBarrier用来实现这些工作者线程中的任意一个线程在执行其操作前必须等待其他线程也准备就绪；
            2. 即实现这些工作者线程尽可能在同一时刻开始其操作
   5. 生产者-消费者模式
      1. 阻塞队列
         1. ArrayBlockingQueue
            1. 内部使用一个数组作为其存储空间，数组的存储空间是预先分配的。
            2. 优点：put和take操作不会增加GC的负担
            3. 缺点：put和take操作使用同一个锁，可能导致锁争用，导致较多的上下文切换
            4. 适合在生产者线程和消费者线程之间的并发程序较低的情况下使用
         2. LinkedBlockingQueue
            1. 内部存储空间是一个链表，而链表节点所需的存储空间是动态分配的
            2. 优点：put和take操作使用两个显示锁（putLock和takeLock）
            3. 缺点：增加了GC的负担
            4. 适合在生产者线程和消费者线程之间的并发程序较高的情况下使用
         3. SynchronousQueue
            1. 可以被看做一种特殊的游街队列
            2. 生产者线程生产一个产品之后，会等待消费者线程来取走这个产品，才会接着生产下一个产品
            3. 适合在生产者线程和消费者线程之间的处理能力相差不大的情况下使用
      2. 流量控制与信号量（Semaphore）
         1. Semaphore用来控制同一时间内对虚拟资源的访问次数
         2. Semaphore.acquire/Semaphore.release分别用于申请和释放许可
         3. Semaphore.acquire（）在成功获得一个许可后会立即返回
         4. 如果可用配额不足，那么会使其执行线程暂停
         5. Semaphore内部会维护一个等待队列用于存储这些被暂停的线程
         6. Semaphore.release必须放在finally语句中，确保执行
      3. 双缓冲和Exchanger
         1. 设立两个缓冲区
         2. 消费者线程消费一个已填充的缓冲区时，另外一个缓冲区可以由生产者线程进行填充，实现数据的生产和消费的并发
   6. 线程停止：
      1. 实现思路：为待停止的线程（目标线程）设置一个线程停止标记（布尔型），目标线程检测到该标志值为true时，设法让其run方法返回，实现线程的终止
      2. 通用的线程优雅停止办法：
         1. 发起线程更新目标线程的线程停止标记并给其发送中断，目标线程仅在当前无待处理任务且不会产生新的待处理任务情况下才能使run方法返回
2. 保障线程安全的设计技术
   1. 线程特有对象（ThreadLocal）
      1. 也叫线程本地变量，这个对象可以创建并访问各自的线程特有对象
      2. 由于线程安全的对象内部往往需要使用锁，因此，多个线程共享线程安全的对象可能导致锁的争用，使用ThreadLocal可以避免锁的使用。
      3. 导致的问题：
         1. 退化与数据错乱
         2. 可能导致内存泄漏、伪内存泄漏
      4. ThreadLocal内部实现机制：
         1. 每个线程内部都会维护一个类似HashMap的对象，称为ThreadLocalMap，里边会包含若干了Entry（K-V键值对），相应的线程被称为这些Entry的属主线程
         2. Entry的Key是一个ThreadLocal实例，Value是一个线程特有对象。Entry的作用即是：为其属主线程建立起一个ThreadLocal实例与一个线程特有对象之间的对应关系
         3. Entry对Key的引用是弱引用；Entry对Value的引用是强引用。
         4. 缺点：一个线程访问过线程局部变量之后如果对该线程有对其可达的强引用，那么该线程的中ThreadLocalMap中的无效条目就不会被清理，导致Entry-Value的线程特有对象无法被垃圾回收，导致了伪内存泄漏
         5. 
      5. 解决伪内存泄漏的办法：
         1. 在当前线程中调用ThreadLocal.remove（）方法将线程特有对象从其所属的Entry中清理即可
      6. ThreadLocal使用场景：
         1. 需要使用非线程安全对象，但又不希望因此而引入锁
         2. 将线程安全对象当做不安全对象使用，可以避免锁的开销
   2. 装饰器模式
      1. 装饰器（Decorator）模式可以用来实现线程安全，基本思想是为非线程安全对象创建一个相应的线程安全的外包装对象（Wrapper）；
      2. 客户端不直接访问非线程安全对象，而是访问其外包装对象
      3. 具体使用：
         1. java.util.Collections.synchronizedSet( new HashSet( ))
         2. java.util.Collections.synchronizedList( new ArrayList( ))
         3. java.util.Collections.synchronizeMap( new HashMap( ))
      4. 以上几个方法都会返回一线程安全的同步集合；
      5. 但是这些同步集合的iterator方法返回的Iterator实例并不是线程安全的，为了保障对同步集合的遍历操作的线程具有安全性，我们需要对遍历操作进行加锁。
   3. 并发集合
      1. 常用的并发集合：
         1. ArrayList----CopyOnWriteArrayList     快照实现遍历
         2. HashSet---CopyOnWriteArraySet        快照实现遍历
         3. LinkedList---ConcurrentLinkedQueue    准实时
         4. HashMap---ConcurrentHashMap       准实时
         5. TreeMap---ConcurrentSkipListMap     准实时
         6. TreeSet---ConcurrentSkipListSet          准实时
      2. 快照（Snapshot）
         1. 是在Iterator实例被创建的那一刻待遍历对象内部结构的一个只读副本；由于对同一个并发集合进行遍历操作的每个线程都会得到一个快照，所以快照相当于这些线程的特有对象。
      3. 准实时：
         1. 指遍历操作不是针对待遍历对象的副本进行的，但又不借助锁来保障线程安全的；
         2. 借助CAS操作或者粒度极小的锁

如果对你有帮助，记得点赞哦~欢迎大家关注我的博客，我会持续更新后续章节学习笔记，可以进群366533258一起交流学习哦~

本群给大家提供一个学习交流的平台，内设菜鸟Java管理员一枚、精通算法的金牌讲师一枚、Android管理员一枚、蓝牙BlueTooth管理员一枚、Web前端管理一枚以及C#管理一枚。欢迎大家进来交流技术。