为什么需要多线程？
列出一些典型的时间周期：
- cpu：现在3.0GHZ的cpu一个指令周期为，0.3ns => 换算人类时间1s
- 内存：寻址时间大概在100ns => 换算人类时间4min
- SSD： 随机读取耗时为 150us => 换算人类时间4.5天
- 硬盘：寻址时间大概是10ms => 换算人类时间10个月
- 网络：本地延迟1ms，全世界走一圈150ms+ => 换算人类时间12.5年
- 虚拟机：重启一次大概4s => 换算人类时间300年
所以假设cpu是人类，按人类的心跳时间1s计算，每次在等待内存硬盘网络处理和数据传输的时间，将是几个月几年几百年来计算的。
多线程的出现
由于CPU的速度实在太快了，一般解决方法是让cpu处理完一批事务后，一次性交于内存
现在CPU都是多核的：根据焦耳定律，频率太快会导致发热量急剧上升，所以频率已经不能再快了，只能往横向多核发展
线程带来了什么问题，如何避免？
- 单线程语言的执行模型是同步/阻塞（block）的
- java默认只有一个线程
Thread
- 每多开⼀个线程，就多⼀个执⾏流
- ⽅法栈(局部变量)是线程私有的
- 静态变量/类变量是被所有线程共享的
当认为任务是可以拆分且互不相关的时候，可以使用多线程加快任务
开启多线程的方式
- new Thread(Callable).start()
- parallelStream
- Executor
- ForkJoinPool
避免多线程问题
多线程的本质问题：你要看着同⼀份代码，想象不同的⼈在疯狂地以乱序执⾏它，而java中默认的实现几乎都不是线程安全的
共享变量中使用多线程，经常就会采坑
- 操作的原子性：即同一时刻只有一个程序在操作
- 在一个事务周期里，只能对数据修改一次
- 保证事务操作的原子性，有些方法本身就是原子操作，则是线程安全的
- 避免死锁
死锁
著名哲学家用餐问题，反映的就是多线程死锁问题，原因在于双方都互相拿着对方的锁，又同时在等待对方释放
预防死锁产⽣的原则：所有的线程都按照相同的顺序获得资源的锁
java中线程安全的基本⼿段
synchronize
使用synchronized同步块，同步块中需要持有一把锁，只有拥有这把锁的线程才能继续下一步，而剩下的线程都需要等待这把锁释放。当锁被释放，剩下的线程公平且随机的竞争这把锁。
- synchronized(⼀个对象) 把这个对象当成锁
- Static synchronized⽅法 把Class对象当成锁
- 实例的synchronnized⽅法把该实例当成锁
- Collections.synchronized
线程调度和等待
可以把线程简单理解为js的异步问题，那么最终的异步都需要有回调，否则同步的代码就会在异步代码前执行完
Java从⼀开始就把线程作为语⾔特性，提供语⾔级的⽀持
- Object.wait()/notify()/notifyAll()⽅法
- 所有对象都是Object的子类，所以都可以成为锁
就是用来解决多线程调度问题
正常主线程需要等待其他线程数据返回后return，主线程依然要使用synchronized块包裹并wait。当其他线程执行完后，需要使用notify来通知正在wait的主线程
基于这三个方法实现的上层工具类：
- ReentrantLock & Condition
- countDownLatch
- BlockingQueue
JUC包
多线程除了要考虑线程调度和等待问题，java中的大多数类都是线程不安全的，此时引入了J.U.C并发包，即 java.util.concurrent包，是JDK的核心工具包,包里的所有类都是线程安全的
如：
- AtomicInteger/...
- ConcurrentHashMap
在任何使⽤有线程安全问题的地⽅都可以在JUC下寻找对应的线程安全类替换。
多线程用途
对于IO密集型应⽤极其有⽤
- ⽹络IO（通常包括数据库）
- ⽂件IO
对于CPU密集型应⽤稍有折扣
性能提升的上限在哪⾥？
- 单核CPU 100%
- 多核CPU N*100%
阶段小结
目前对多线程的理解浅显，缺乏实战经验。
未完待续。。
期待了解和解决的问题：
- 什么是ThreadLocal？
- 为什么需要线程池？
- 线程池的构造函数中的参数都是什么含义？
