java多线程记录

为什么需要多线程？

CPU,这个世界慢死了

列出一些典型的时间周期：

• 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？
• 为什么需要线程池？
• 线程池的构造函数中的参数都是什么含义？