来源：blog.csdn.net/wangwenpeng0529/article/details/
在 Java 5.0 提供了 (简称JUC)包,在此包中增加了在并发编程中很常用的工具类,用于定义类似于线程的自定义子系统,包括线程池,异步 IO 和轻量级任务框架;还提供了设计用于多线程上下文中的 Collection 实现等
内存可见性（Memory Visibility）是指当某个线程正在使用对象状态而另一个线程在同时修改该状态，需要确保当一个线程修改了对象状态后，其他线程能够看到发生的状态变化。
可见性错误是指当读操作与写操作在不同的线程中执行时，我们无法确保执行读操作的线程能适时地看到其他线程写入的值，有时甚至是根本不可能的事情。
我们可以通过同步来保证对象被安全地发布。除此之外我们也可以使用一种更加轻量级的 volatile 变量。
Java 提供了一种稍弱的同步机制，即 volatile 变量，用来确保将变量的更新操作通知到其他线程。可以将 volatile 看做一个轻量级的锁，但是又与锁有些不同：
- 对于多线程，不是一种互斥关系
- 不能保证变量状态的“原子性操作
问题代码示例
两个线程同时修改这一个flag，为什么main拿到的还是这种修改之前的值
内存分析
解决方法，加锁
加了锁，就可以让while循环每次都从主存中去读取数据，这样就能读取到true了。但是一加锁，每次只能有一个线程访问，当一个线程持有锁时，其他的就会阻塞，效率就非常低了。不想加锁，又要解决内存可见性问题，那么就可以使用volatile关键字。
volatile
volatile 关键字：当多个线程进行操作共享数据时，可以保证内存中的数据可见。相较于 synchronized 是一种较为轻量级的同步策略。
注意：
- volatile 不具备“互斥性”
- volatile 不能保证变量的“原子性”
所谓原子性就是操作不可再细分
问题代码
看到这里，好像和上面的内存可见性问题一样。是不是加个volatile关键字就可以了呢？其实不是的，因为加了volatile，只是相当于所有线程都是在主存中操作数据而已，但是不具备互斥性。比如两个线程同时读取主存中的0，然后又同时自增，同时写入主存，结果还是会出现重复数据。
AtomicInteger这个玩意是具有原子性的integer，用它替换后发现能保证线程安全
解决了原子性问题，解决了内存可见性的问题
CAS (Compare-And-Swap) 是一种硬件对并发的支持，针对多处理器操作而设计的处理器中的一种特殊指令，用于管理对共享数据的并发访问。CAS 是一种无锁的非阻塞算法的实现。
CAS 包含了 3 个操作数：
- 需要读写的内存值 V 进行比较的值 A 拟写入的新值 B
- 当且仅当 V 的值等于 A 时， CAS 通过原子方式用新值 B 来更新 V 的值，否则不会执行任何操作。
- CAS比较失败的时候不会放弃CPU，会反复执行，直到自己修改主内存的数据
小工具包，支持在单个变量上解除锁的线程安全编程。事实上，此包中的类可将 volatile 值、字段和数组元素的概念扩展到那些也提供原子条件更新操作的类。
类 AtomicBoolean、 AtomicInteger、 AtomicLong 和 AtomicReference 的实例各自提供对相应类型单个变量的访问和更新。每个类也为该类型提供适当的实用工具方法。
AtomicIntegerArray、 AtomicLongArray 和 AtomicReferenceArray 类进一步扩展了原子操作，对这些类型的数组提供了支持。这些类在为其数组元素提供 volatile 访问语义方面也引人注目，这对于普通数组来说是不受支持的。
核心方法：
java.util.concurrent.atomic 包下提供了一些原子操作的常用类:
线程安全的hash表 每一段都是一个独立的锁
Java 5.0 在 包中提供了多种并发容器类来改进同步容器的性能。
ConcurrentHashMap 同步容器类是Java 5 增加的一个线程安全的哈希表。对与多线程的操作，介于 HashMap 与 Hashtable 之间。内部采用“锁分段”机制替代 Hashtable 的独占锁。进而提高性能。
此包还提供了设计用于多线程上下文中的 Collection 实现：ConcurrentHashMap、 ConcurrentSkipListMap、 ConcurrentSkipListSet、CopyOnWriteArrayList 和 CopyOnWriteArraySet。当期望许多线程访问一个给定 collection 时， ConcurrentHashMap 通常优于同步的 HashMap，ConcurrentSkipListMap 通常优于同步的 TreeMap。当期望的读数和遍历远远大于列表的更新数时， CopyOnWriteArrayList 优于同步的 ArrayList。
ConcurrentHashMap就是一个线程安全的hash表。我们知道HashMap是线程不安全的，Hash Table加了锁，是线程安全的，因此它效率低。HashTable加锁就是将整个hash表锁起来，当有多个线程访问时，同一时间只能有一个线程访问，并行变成串行，因此效率低。所以JDK1.5后提供了ConcurrentHashMap，它采用了锁分段机制。
1.8以后底层又换成了CAS，把锁分段机制放弃了。CAS基本就达到了无锁的境界。
另外，Java 8+ 系列面试题和答案全部整理好了，微信搜索Java技术栈，在后台发送：面试，可以在线阅读。
闭锁，在完成某些运算时，只有其他所有线程的运算全部完成，当前运算才继续执行，Java 5.0 在 包中提供了多种并发容器类来改进同步容器的性能。
CountDownLatch 一个同步辅助类，在完成一组正在其他线程中执行的操作之前，它允许一个或多个线程一直等待。
闭锁可以延迟线程的进度直到其到达终止状态，闭锁可以用来确保某些活动直到其他活动都完成才继续执行：
- 确保某个计算在其需要的所有资源都被初始化之后才继续执行;
- 确保某个服务在其依赖的所有其他服务都已经启动之后才启动;
- 等待直到某个操作所有参与者都准备就绪再继续执行。
Java 5.0 在 提供了一个新的创建执行线程的方式：Callable 接口
Callable 接口类似于 Runnable，两者都是为那些其实例可能被另一个线程执行的类设计的。但是 Runnable 不会返回结果，并且无法抛出经过检查的异常。
Callable 需要依赖FutureTask ， FutureTask 也可以用作闭锁。
在 Java 5.0 之前，协调共享对象的访问时可以使用的机制只有 synchronized 和 volatile 。Java 5.0 后增加了一些新的机制，但并不是一种替代内置锁的方法，而是当内置锁不适用时，作为一种可选择的高级功能。
ReentrantLock 实现了 Lock 接口，并提供了与synchronized 相同的互斥性和内存可见性。但相较于synchronized 提供了更高的处理锁的灵活性。
生产者等待，增加出问题的几率 库存空位改成1
消费者等于0的时候， 两个消费者同时生产，之后停住了，没有其他线程去唤醒，导致停在生产者这里。
解决方法，去掉else，让他能走唤醒方法。
让线程能走到notifyall，可以避免停止在生产者这里。
增加到两个消费者两个生产者之后，如果现在没有库存，两个消费者都停止在wait，然后出现生产者将库存加一，唤醒所有消费者，这时候就出现了两个消费者同时去消费一个库存，导致库存变成负数，这就是虚假唤醒。
在object类的wait方法中，虚假唤醒是可能的，因此这个wait方法应该总被使用在循环中
解决方法
将代码中的if换为while循环执行
Condition 接口描述了可能会与锁有关联的条件变量。这些变量在用法上与使用 Object.wait 访问的隐式监视器类似，但提供了更强大的功能。需要特别指出的是，单个 Lock 可能与多个 Condition 对象关联。为了避免兼容性问题， Condition 方法的名称与对应的 Object 版本中的不同。
在 Condition 对象中，与 wait、 notify 和 notifyAll 方法对应的分别是await、 signal 和 signalAll。Condition 实例实质上被绑定到一个锁上。要为特定 Lock 实例获得Condition 实例，请使用其 方法。
这里店员的代码全部处理为condition，用他的方法实现线程的通信。
编写一个程序，开启 3 个线程，这三个线程的 ID 分别为A、 B、 C，每个线程将自己的 ID 在屏幕上打印 10 遍，要求输出的结果必须按顺序显示。
如：ABCABCABC…… 依次递归9-ReadWriteLock 读写锁读-写锁 ReadWriteLock
ReadWriteLock 维护了一对相关的锁，一个用于只读操作，另一个用于写入操作。只要没有 writer，读取锁可以由多个 reader 线程同时保持。写入锁是独占的。
ReadWriteLock 读取操作通常不会改变共享资源，但执行写入操作时，必须独占方式来获取锁。对于读取操作占多数的数据结构。ReadWriteLock 能提供比独占锁更高的并发性。而对于只读的数据结构，其中包含的不变性可以完全不需要考虑加锁操作。
读锁是多个线程可以一起，写锁是独占的
线程八锁
- 一个对象里面如果有多个synchronized方法，某一个时刻内，只要一个线程去调用其中的一个synchronized方法了，其它的线程都只能等待，换句话说，某一个时刻内，只能有唯一一个线程去访问这些synchronized方法
- 锁的是当前对象this，被锁定后，其它的线程都不能进入到当前对象的其它的synchronized方法
- 加个普通方法后发现和同步锁无关
- 换成两个对象后，不是同一把锁了，情况立刻变化。
- 都换成静态同步方法后，情况又变化
- 所有的非静态同步方法用的都是同一把锁——实例对象本身，也就是说如果一个实例对象的非静态同步方法获取锁后，该实例对象的其他非静态同步方法必须等待获取锁的方法释放锁后才能获取锁，可是别的实例对象的非静态同步方法因为跟该实例对象的非静态同步方法用的是不同的锁，所以毋须等待该实例对象已获取锁的非静态同步方法释放锁就可以获取他们自己的锁。
- 所有的静态同步方法用的也是同一把锁——类对象本身，这两把锁是两个不同的对象，所以静态同步方法与非静态同步方法之间是不会有竞态条件的。但是一旦一个静态同步方法获取锁后，其他的静态同步方法都必须等待该方法释放锁后才能获取锁，而不管是同一个实例对象的静态同步方法之间，还是不同的实例对象的静态同步方法之间，只要它们同一个类的实例对象！
线程八锁的关键：
- 非静态方法的锁默认为 this, 静态方法的锁为 对应的 Class 实例
- 某一个时刻内，只能有一个线程持有锁，无论几个方法。
第四种获取线程的方法：线程池，一个 ExecutorService，它使用可能的几个池线程之一执行每个提交的任务，通常使用 Executors 工厂方法配置。
线程池可以解决两个不同问题：由于减少了每个任务调用的开销，它们通常可以在执行大量异步任务时提供增强的性能，并且还可以提供绑定和管理资源（包括执行任务集时使用的线程）的方法。每个 ThreadPoolExecutor 还维护着一些基本的统计数据，如完成的任务数。
为了便于跨大量上下文使用，此类提供了很多可调整的参数和扩展钩子 (hook)。但是，强烈建议程序员使用较为方便的 Executors 工厂方法 ：
- （无界线程池，可以进行自动线程回收）
- （固定大小线程池）
- （单个后台线程）它们均为大多数使用场景预定义了设置。
一个 ExecutorService，可安排在给定的延迟后运行或定期执行的命令。
就是在必要的情况下，将一个大任务，进行拆分(fork)成若干个小任务（拆到不可再拆时），再将一个个的小任务运算的结果进行 join 汇总。
JoinFork/Join 框架与线程池的区别
采用 “工作窃取”模式（work-stealing）：
- 当执行新的任务时它可以将其拆分分成更小的任务执行，并将小任务加到线程队列中，然后再从一个随机线程的队列中偷一个并把它放在自己的队列中。
- 相对于一般的线程池实现， fork/join框架的优势体现在对其中包含的任务的处理方式上。在一般的线程池中， 如果一个线程正在执行的任务由于某些原因无法继续运行， 那么该线程会处于等待状态。而在fork/join框架实现中，如果某个子问题由于等待另外一个子问题的完成而无法继续运行。那么处理该子问题的线程会主动寻找其他尚未运行的子问题来执行.这种方式减少了线程的等待时间， 提高了性能。
近期热文推荐：
1.1,000+ 道 Java面试题及答案整理(2021最新版)
2.别在再满屏的 if/ else 了，试试策略模式，真香！！
3.卧槽！Java 中的 xx ≠ null 是什么新语法？
4.Spring Boot 2.5 重磅发布，黑暗模式太炸了！
5.《Java开发手册（嵩山版）》最新发布，速速下载！
觉得不错，别忘了随手点赞+转发哦！
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.bianchenghao6.com/java-jiao-cheng/16018.html