什么是并发编程？
跳出来看全局就是3部分：分工、协作、互斥
钻进去看本质：技术的本质就是背后的理论模型
并发理论基础
并发编程产生bug的原因
- 可见性：cpu缓存导致共享变量在多核cpu的情况下，不可见，所以计算会出错
- 原子性：高级语言中的一个操作可能是操作系统中多个操作，如count + =1 ，其实对应操作系统3步操作「1、count从内存加载到cpu寄存器；2、寄存器执行+1操作；3、将结果写回内存（缓存机制可能回写回cpu缓存而不是内存）」
- 有序性：编译优化后，代码执行顺序可能发生变化
Java内存模型，如何解决可见性和有序性问题
方案：按需禁用缓存以及编译优化
方法：volatile,synchronzied,final关键字，六项Happens-Before规则
- volatile：告诉编译器禁用cpu缓存，必须从内存中读写变量（解决可见性）
- final： 告诉编译器这个变量不会变，随便进行编译优化（解决编译优化顺序性和原子性）
- 六项Happens-Before规则：前面一个操作的结果对后续是可见的。（解决可见性问题和编译优化顺序性）
原子性问题
源头：线程切换
解决方案：锁，互斥锁，一把锁可以保护多个资源
加锁本质就是在锁对象的对象头中写入当前线程id
用不同的锁对受保护资源进行精细化管理，能够提升性能。这种锁还有个名字，叫细粒度锁，会有死锁问题
锁的资源：无关联资源可用各自对象，有关联资源可用class对象，class对象是Java虚拟机加载类时创建的，具有唯一性
如何避免死锁
产生的条件：互斥、占有资源A等待资源B且不释放资源A、其他资源不能强行抢占资源、循环等待
解决办法：破坏其中一个条件
破坏占有且等待条件：由一个单例类来分配资源
破坏不可抢占条件：主动释放资源可用Lock，synchroized做不到
破坏循环等待条件：资源进行排序，等待-通知机制
活锁
原因：线程永久阻塞，类似两个人过同一个门，都走左边，然后互相谦让又都走右边，一直循环下去
方案：添加一个随机的等待时间
线程饥饿
原因：优先级低的线程获取锁的机会小，持有锁的线程执行时间长
方案：公平锁，线程等待有先来后到，获取锁的机会平等
性能问题
阿姆达尔定律：
公式里的 n 可以理解为 CPU 的核数，p 可以理解为并行百分比，那（1-p）就是串行百分比了，也就是我们假设的 5%。我们再假设 CPU 的核数（也就是 n）无穷大，那加速比 S 的极限就是 20。
方案：
- 无锁算法和数据结构，例如线程本地存储 (Thread Local Storage, TLS)、写入时复制 (Copy-on-write)、乐观锁等；Java 并发包里面的原子类也是一种无锁的数据结构；Disruptor 则是一个无锁的内存队列，性能都非常好……
- 减少锁持有时间，增加并行度，如：细粒度锁，分段锁，读写锁
管程
解决互斥问题思路：将共享变量及其对共享变量的操作封装起来。
解决同步问题思路：条件变量等待队列
线程生命周期
可通过jstack或Java VisualVm可视化工具查看线程栈信息
创建多少线程合适
I/O密集型：最佳线程数 =CPU 核数 * [ 1 +（I/O 耗时 / CPU 耗时）]
CPU密集型：线程的数量 =CPU 核数
并发工具类
Lock和Condition
Lock和synchoronized的区别：
sync申请资源如果申请不到，线程直接阻塞，无法释放
Lock能够响应中断、支持超时、非阻塞的获取锁
// 支持中断的API
void lockInterruptibly() throws InterruptedException;
// 支持超时的API
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
// 支持非阻塞获取锁的API
boolean tryLock();
Lock如何保证可见性：内部维护了用volatile的state字段
可重入锁：线程可以重复获取同一把锁
公平锁和非公平锁：ReentrantLock 这个类有两个构造函数，一个是无参构造函数，一个是传入 fair 参数的构造函数。fair 参数代表的是锁的公平策略，如果传入 true 就表示需要构造一个公平锁，反之则表示要构造一个非公平锁。公平锁从等待队列里唤醒等待时间最长的线程，非公平锁则不保证。
用锁最佳实践
- 永远只在更新对象的成员变量时加锁
- 永远只在访问可变的成员变量时加锁
- 永远不在调用其他对象的方法时加锁