JavaEE(3)多线程进阶

一、各种锁策略目录一、各种锁策略1、悲观锁 VS 乐观锁2、轻量级锁 VS 重量级锁3、自旋锁4、公平锁 vs 非公平锁5、可重入锁6、读写锁 ReentrantReadWriteLock二、CASCompare And Swap比较并交换——乐观锁的底层实现CAS能干什么ABA问题CAS的坑零基础重点理解三、synchronized底层原理JDK1.8锁升级1、偏向锁没有竞争的时候2、轻量级锁少量竞争用CAS自旋3、重量级锁竞争非常激烈JVM两个锁优化编译器自动帮我们做四、JUC工具包java.util.concurrent1、Callable FutureTask2、ReentrantLock 手动锁3、原子类4、线程池5、Semaphore信号量6、CountDownLatch五、线程安全集合六、死锁死锁4个必要条件七、小贴士锁相当于卫生间门锁。拿到锁才能进卫生间别人就得在外面等。1、悲观锁 VS 乐观锁悲观锁心里默认别人一定会抢这个资源。每次要操作共享数据先上锁。别人想操作就堵在外面等待。例子去公共卫生间进去第一件事就把门反锁。默认外面肯定有人也要上厕所。特点只要我要用先锁住防止别人捣乱。Java例子锁竞争激烈时候的synchronized。乐观锁心里默认大概率没人跟我抢。不上锁。我直接操作数据等到修改完毕那一刻才检查有没有人中途改过。如果发现被别人改过了本次操作失败重新再来一遍。生活例子自习室座位。我直接坐下不加锁坐下来之后才看座位是不是已经被别人占了。被占了就换座位重试。特点不加锁靠检查判断冲突。CAS就是乐观锁的实现。怎么选很多线程抢数据冲突多→ 悲观锁合适很少有人抢冲突少→ 乐观锁合适补充Javasynchronized一开始乐观抢锁的线程多了自动变成悲观锁。2、轻量级锁 VS 重量级锁先懂两个名词用户态、内核态类比银行办业务用户态你自己在大厅能搞定的事速度快。内核态必须叫银行柜台工作人员帮你处理要排队切换过去很慢开销巨大。重量级锁必须拜托操作系统内核帮忙加锁。会频繁在用户态、内核态来回切换速度慢开销大。卫生间门锁找保安帮忙锁门。轻量级锁尽量自己用户态搞定加锁尽量不去麻烦操作系统。实在搞不定了才去找操作系统。开销小。synchronized一开始轻量级锁线程抢锁特别凶升级成重量级锁。3、自旋锁普通锁抢不到锁怎么办线程直接躺平休眠CPU不给它分配时间。等锁释放操作系统再把它唤醒。休眠唤醒开销很大。自旋锁抢不到锁不睡觉原地循环反复尝试抢锁。伪代码大白话while(锁被别人拿着){ 再试一次抢锁 }生活例子奶茶店。普通挂起锁点不到单回家睡觉等店家打电话通知你再来。自旋锁站柜台门口不停问店员“好了吗好了吗”不离开。优点锁很快就释放的场景不需要休眠唤醒一旦锁释放立刻拿到锁速度快。缺点如果别人拿着锁很久不放你一直在循环询问白白消耗CPU算力。synchronized轻量级锁底层就是自适应自旋JVM自己判断自旋几次拿不到就不再自旋直接休眠。4、公平锁 vs 非公平锁假设3个线程排队等锁A释放。公平锁先来后到。锁释放谁等的时间最久谁优先拿到。排队买火车票严格按排队顺序。代价需要记录排队顺序有额外开销。非公平锁不看排队顺序。锁一释放新来的线程和排队老线程一起抢夺谁抢到算谁。公交车开门大家一拥而上不看谁先来。操作系统原生就是非公平。synchronized只能是非公平锁ReentrantLock可以设置开启公平锁。5、可重入锁场景同一个线程已经拿到锁了还没释放代码又要再次拿同一把锁。可重入锁允许不会卡死。记录加锁次数加锁1解锁‑1。你家卫生间你已经锁上门在里面。你又想再锁一次门重复上锁不会把自己关死。不可重入锁再次加锁直接堵死自己发生死锁。Java中synchronized、ReentrantLock都是可重入锁。Linux底层mutex是不可重入锁。6、读写锁 ReentrantReadWriteLock场景大量读数据很少修改数据。比如网站文章成千上万人看文章读很少有人修改文章写。普通锁synchronized不管读还是写全部互斥。大家读文章也要排队性能很差。读写锁把锁分成两把读锁、写锁读锁读锁不互斥很多线程同时读大家一起看文章没问题写锁写锁互斥同一时间只能一个人写读锁写锁互斥。有人在读就不能写有人在写就不能读。适用场景读多写少。注意synchronized不是读写锁。二、CASCompare And Swap比较并交换——乐观锁的底层实现CAS是CPU硬件提供的指令硬件保证整个操作不可分割原子。三个角色V内存里真实存的数据A我预期旧值我之前读到的值B我想要改成的新值CAS做三件事一步完成不能被打断比较判断内存V 和我的预期旧值A 是否相等如果相等证明没人改过数据把B写入V返回成功。如果不相等说明中途别人修改过不修改直接返回失败。伪代码逻辑演示代码本身不是原子真正靠CPU硬件booleanCAS(内存地址,预期A,新值B){if(内存的值A){内存B;returntrue;}returnfalse;}CAS能干什么实现原子类AtomicInteger比如多线程做i普通i线程不安全用AtomicInteger底层循环CAS失败就重试。实现自旋锁。ABA问题CAS的坑零基础重点理解问题CAS只比较数值不关心中间发生过什么变化。举例子内存变量num A线程t1读到旧值A准备执行CAS把它改成Z。在t1执行CAS之前线程t2把num从A→改成B又改回A。t1执行CAS一看内存还是A以为没人修改过直接修改为Z。问题变量中间明明被修改过只是最后变回原来的值CAS识别不出来产生bug。生活类比二手机。手机原本A卖给BB翻新一遍再变回外观A卖给你。你只看外表看不出被转手过。解决方案版本号。不光比较数据值还要额外带一个版本号。每次修改版本号1。哪怕数值变回A版本号已经变大CAS就知道数据被改动过操作失败。Java工具类AtomicStampedReference存数据版本号。三、synchronized底层原理JDK1.8锁升级synchronized不是简单的一把锁它会根据竞争激烈程度自动升级锁状态无锁 → 偏向锁 → 轻量级锁自适应自旋 → 重量级锁锁只能升级不能降级。1、偏向锁没有竞争的时候大部分场景锁一直只被同一个线程使用没有别的线程抢锁。偏向锁不做真正加锁操作仅仅在对象的对象头记录这个锁归哪个线程。家里卫生间只有你一个人用不需要每次都拧门锁只做个标记这个卫生间是你的。如果没有其他线程来抢锁不加锁解锁节省大量开销。一旦来了第二个线程竞争锁立刻撤销偏向锁升级为轻量级锁。一句话偏向锁能不加锁就不加锁延迟加锁。2、轻量级锁少量竞争用CAS自旋有别的线程开始抢锁。使用CAS自旋抢锁。不会无限循环自旋JVM自适应自旋几次拿不到锁就停止自旋。3、重量级锁竞争非常激烈自旋反复尝试拿不到锁继续自旋会疯狂消耗CPU。于是膨胀成重量级锁去找操作系统mutex。抢不到锁的线程直接休眠挂起进入操作系统等待队列锁释放后操作系统唤醒线程。用户态内核态切换开销很大。JVM两个锁优化编译器自动帮我们做锁消除代码写了synchronized但是根本不会有多线程跑这段代码。JVM直接把锁删掉。单线程使用StringBuffer每一步append自带synchronizedJVM把锁全部消除避免无用开销。锁粗化代码里循环反复加锁→解锁→加锁→解锁。JVM合并变成一次加锁循环执行最后一次解锁。打电话不要打一次说一句话挂掉打通电话一次性把所有话说完再挂。减少重复打电话开销。四、JUC工具包java.util.concurrentJUC就是Java给多线程准备的工具箱解决各种并发问题。1、Callable FutureTaskRunnable线程任务run()没有返回值。做完不知道结果。Callable线程任务call()可以返回结果还能抛异常。Callable不能直接丢给Thread。必须包装到FutureTask。主线程调用futureTask.get()会阻塞等待子线程执行完毕拿到返回结果。类比外卖下单Callable任务拿到小票FutureTaskget()就是凭小票等外卖送到手上。2、ReentrantLock 手动锁也是可重入锁功能和synchronized类似但是更加灵活。基础写法必须写finally里面unlock解锁防止异常死锁ReentrantLocklocknewReentrantLock();lock.lock();//加锁try{//线程安全代码}finally{lock.unlock();//手动解锁}对比synchronizedReentrantLock类型关键字JVM底层实现Java普通类释放锁代码出块自动释放必须手动unlock等待抢不到锁死等tryLock(时间)可以超时放弃公平锁只能非公平可以打开公平锁等待唤醒wait/notify随机唤醒线程Condition精准唤醒某一组线程简单选择竞争不激烈简单代码优先synchronized简单不容易出错。需要超时、公平锁、精准唤醒选ReentrantLock。3、原子类AtomicInteger、AtomicLong、AtomicStampedReference。全部底层CAS不加锁适合简单计数。4、线程池问题频繁new Thread创建销毁线程开销大。线程池提前准备一批线程放在池子里。任务来了复用旧线程不用反复创建销毁。两种创建方式Executors.newFixedThreadPool()工厂快速创建。生产环境不推荐参数默认容易出问题。ThreadPoolExecutor完整构造7个参数企业开发标准。7个参数通俗解释开公司类比corePoolSize核心线程数正式员工不随便辞退。maximumPoolSize最大线程数正式员工临时工总上限。keepAliveTime临时工空闲多久就开除。unit时间单位秒/毫秒。workQueue阻塞队列待办任务的排队队列。活多了先写到队列排队。threadFactory线程工厂负责造线程招聘。handler拒绝策略公司彻底忙不过来了新来任务怎么处理。AbortPolicy直接抛异常默认CallerRunsPolicy提交任务的线程自己干活DiscardOldestPolicy丢掉排队最久的任务DiscardPolicy直接丢掉新来任务线程池干活流程来了任务如果正式员工还没招满 → 创建正式员工干活。正式员工全部忙完 → 任务丢进排队队列。队列塞满还没到最大总人数 → 创建临时工干活。队列满、也达到最大人数 → 执行拒绝策略。5、Semaphore信号量控制最多多少个线程同时执行相当于计数器。停车场一共4个车位。acquire()停车申请车位计数器‑1没车位就阻塞等待。release()开车离开释放车位计数器1。6、CountDownLatch等待N个任务全部干完主线程再继续往下跑。跑步比赛10个选手全部跑到终点裁判才公布成绩。new CountDownLatch(10)一共有10个任务。每个任务结束调用countDown()计数器‑1。主线程调用await()阻塞直到计数器变成0才继续运行。五、线程安全集合普通HashMap、ArrayList多线程直接使用会报错、数据错乱。Hashtable老的线程安全哈希表。所有方法synchronized锁住整个对象性能很差不推荐使用。ConcurrentHashMap(JDK1.8)不再锁整个map锁哈希桶头结点。只有访问同一个链表/红黑树桶的线程才竞争锁冲突大大减少。读操作不加锁volatile保证读到最新数据写操作synchronizedCAS。链表长度8转红黑树。扩容多线程帮忙一起搬迁数据不是单线程搬运全部数据。CopyOnWriteArrayList 写时复制集合写数据的时候复制一份全新数组修改新数组修改完成把引用指向新数组。读不加锁。适合读多写少内存占用大写的数据不能立刻读到。六、死锁死锁多个线程各自拿着对方想要的锁互相等待谁都不肯释放全部卡死不动程序僵住。生活化例子两个人吃饭一个拿到酱油一个拿到醋。A把醋给我我才把酱油给你。B把酱油给我我才把醋给你。两个人僵住谁也吃不了饭。死锁4个必要条件必须全部同时满足才会死锁破坏任意一个就不会死锁互斥锁资源同一时间只能给一个线程。不可抢占锁不能硬抢必须持有者主动释放。请求并保持线程拿到锁A不释放A还想去拿锁B。循环等待形成闭环。线程1拿A等B线程2拿B等A。最简单解决思路破坏循环等待。所有线程拿多把锁严格固定顺序拿锁。全部先拿锁1再拿锁2就不会出现环路等待。七、小贴士volatile只保证内存可见性、禁止指令重排不保证原子性。不能替代锁做i。线程状态NEW新建、RUNNABLE可运行、BLOCKED锁阻塞、WAITING无限等待、TIMED_WAITING限时等待、TERMINATED结束。进程操作系统资源分配最小单位线程CPU调度最小单位。同一个进程里面多个线程共享堆内存所以会产生线程安全问题。