java 多线程总结
-----------------线程的锁--------------------
1.Synchroized
前提:八股看了一遍又一遍,每次看这个 Synchroized 都有点不同,这次把整体总结一下
用处:同步代码块、同步方法
对于非静态的一般上锁就是针对当前的对象实例;而对于静态的则针对的当前类的所有对象,因为对于类的信息我们是存在方法区的,JVM 中只有一份。
对象:一个对象在存储中,包含了对象头、实例数据、对其数据。而对象头又包含了 MarkWord、类指针(指向类的信息),而对于锁这一部分,其实主要是 MarWord 这一部分:分代年龄(GC)、hashCode(HashMap)、标记位(这一部分标记了无锁、偏向锁、轻量级锁、重量级锁)
简单说一下:无锁、偏向锁(只有一个线程)、轻量级锁(多个线程顺序执行)、重量级锁(抢锁),当然还有自旋锁,自适应自旋锁等。
所以对于锁来说,其实就是对象监视器来针对当前对象的对象头的标志位的一个抢占(对于类的话,应该是类对象吧,只有一个),主要以对象头标志抢占为主:
拥有对象监视器(锁)的线程
其他线程来的时候会进行 cas 抢锁,抢不到进到等待队列中(竞争队列、候选队列),因为可能同时有大量线程在等待队列中,所以我们将一部分线程拿到候选队列,作为下一次的锁的优先竞争者
Ondesk,下一次获取锁的线程,在当前线程释放锁之后,会在候选队列的一个线程中唤醒一个指定到 Ondesk,然后再开始竞争,这里的竞争主要是 Ondesk 线程和此时正在 cas 的线程,所以这是竞争切换,明显不公平
还有一个阻塞队列,是调用 wait 函数的线程,会把当前对象的锁释放,然后把当前线程放到阻塞队列中,只有其他线程进行 notify 唤醒,才可以重新进入等待队列的候选队列
注:三种队列:等待队列(竞争队列+候选队列)、阻塞队列、运行的线程、下次竞争的线程
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
2. ReetrantLock
顺便把它讲了吧,这是 JDK 实现的,而上面的是内置的;并且 ReentrantLock 需要手动释放锁,出现异常可能会产生死锁,而 Synchronized 会自动释放;两者都是非公平锁+可重入锁,但是前者(lock)可以实现公平锁,并且可中断。
内部最重要的可以说是 AQS-队列抽象同步器
继承它的内部类分别实现了公平锁、和非公平锁
思想:一个是 state 状态 = c、一个是线程队列
1.公平锁
刚开始不会直接 CAS 抢锁
if c == 0
判断队列是否为空,为空则 cas 抢锁,c = 1;否则加入队列
else 可重入(一般判断线程名是否相等)
加入队列
2.非公平锁
直接 cas 抢锁(明显不公平)
if c == 0
cas 抢锁成功 c ==1;失败加入队列
else 可重入
加入队列
注:可以看到其实和 synchroized 一样都是刚开始进行 cas 抢锁,明显不公平。
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
3. 线程池
继续--------
为什么需要?1.可以进行重用,来任务的时候快速的启动,避免线程的销毁 2.线程池统一管理、统一分配
参数:核心线程数量、最大线程数量、存活时间、单位、阻塞队列、拒绝策略、线程工厂
常见的几种线程池:
newFixedPoolThread(n,n,0,s,LinkedBlockingQuene)
newSinglePoolThread(1,1,0,s,LinkedBlockedQueue)
newCachePoolThread(0,Max_Value,60,s,SynchronousQuene)
newSchedulePoolThread--定时执行
工作原理:对于新来的任务
创建核心线程
核心线程数量达到最大,进入队列
队列满了,创建非核心线程
都满了,则拒绝策略
时间到了,非核心线程死亡
拒绝策略:
直接丢弃
丢弃 + 并抛出异常
抛弃队列队首,加入当前线程
调用当前任务的线程代为执行
阻塞队列:
LinkedBlockingQueue 无穷大
SynchronousQueue 不存储任何线程
还有其他的就不一一列举了
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
4.另一种锁:LockSupport
内部解析:
维护一个类似于信号量的值 Counter = 0 /1
park()方法,进行阻塞
unpark(线程名)方法,进行唤醒
有个问题?
1.如果先唤醒,在阻塞怎么办?
答:不会受影响
2.如果唤醒两次,阻塞两次会怎么办??
答:会阻塞,因为唤醒两次 Counter 的值也就是 1,而阻塞第二次就会判断为 0,而真正的阻塞。
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
5. 乐观锁(补充)
1.cas 实现
主要是判断两次的值是否变化,while 循环一直尝试(自旋锁)
三个参数:(期望的值,当前的值,修改的值)
AtomicInteger:原子类就是这个原理,但是其内部其实是调用 unsafe 类,这个类在底层是直接获取变量的地址,通过比较地址的值来进行比较。
2.版本号实现
在 cas 的基础上加了 version
主要防止 ABA 问题,每次操作都会在 version.+1,只有同时满足 version 相等,并且 cas 为 true,才有意义。
java 中主要实现的是:AtomicStampReference
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
6. JMM
非常类似于 cpu + 内存 + 高度 cache
JMM : cpu + 线程 cache + 内存(jvm 的内存)
java 内存模型在实现上有着“happen-before”的规则:
1.单线程下,前面的代码>后面的代码
2.释放锁>获取锁
3.一个线程的 start 方法>后续操作
4.join 的线程>被 join 的线程
5.volatile 的写>读
6.传递性
三种特性:
可见性、有序性、原子性
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
7.轻量级锁 volatile
保证了可见性 + 有序性
可见性:对于 volatile 修饰的变量,当我们使用的时候,会优先从内存读取,这就保证了缓存失效的原则;即读和取都要从内存中,让不是缓存。
有序性:禁止指令重排序,内部有内存屏障,保证了顺序执行。
原子性:无法保证
场景:
1.状态量标记 volatile boolean flag;一个线程写,一个线程读
2.单例
双重 if + volatile
对于 single = new SingleInstance();
分为三步:
1.为变量开辟空间,分配内存 ;2.为对象实例化赋值 3;引用指向内存地址
可能会变成 1 3 2,如果其中 1 3 执行完,切换到另一个线程,那么此时我们的变量会不是空,但是有一个问题,就是没有初始化,所以会报错。
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
8.volatile 和 Synchronized 的比较
前者无法保证原子性,后者可以
前者轻量级锁,后者重量级锁
前者主要用于变量,后者主要是方法/代码块
前者主要体现内存的可见性,后者主要是访问资源的同步性
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
------------------线程通信方式----------------------
这三个也是面试常问的,作为线程通信的方法
1.CountDownLatch(CDL)
主要是用于一个线程等待其他完成后才继续执行。
主要方法:await()、countDown()
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
2.CyclicBarrier
回环栅栏:主要是用于多个线程在某个点/状态同时执行。
主要方法:await()
注:其 await(long timeout,TimeUnit unit)重载方法,让已到达的线程等待至一定的时间,如果还没有到达指定的数量,则这些开始执行。
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
3.Semaphore
信号量:主要控制访问临界资源的线程数量
主要方法:acqurie()、release()
总结:前两者主要是实现线程之间的等待,而 semaphore 主要是控制对资源的访问
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
4.生产者、消费者
开始撸代码了:
4.1 Synchronized
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
4.2 ReentrantLock
参考链接:https://blog.csdn.net/jike11231/article/details/112792709
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
----------------线程:ThreadLocal---------------------
目的:每个线程都有自己的变量,线程间的数据的互相隔离,互不影响,存储在每个线程的 ThreadLocalMap 变量中,是一种类似于 HashMap 的结构,但是不一样,其没有链表,并且使用的是线性探测法。
1.7 的 ThreadLocal
1.7 的 threadlocalmap-
但是,这明显有个问题,如果线程过多(当然一般线程也是多的),那么 Entry 的数量会很多;并且 Thread 销毁后,ThreadLocal 不能销毁,因为不止一个线程,所以 1.8 进行了改进,主要看 1.8 的 ThreadLocal。
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
1.8 的 ThreadLocal
如上图:一个线程一个 ThreadLocalMap,看源码发现:threadlocalMap 其实定义是在 Threadlocal 内部的,有点意思啊
基本使用 1
基本使用 2
为每个线程分配一个 JDBC 连接 Connection。这样就可以保证每个线程的都在各自的 Connection 上进行数据库的操作,不会出现 A 线程关了 B 线程正在使用的 Connection;
主要方法就是在每个线程中使用 set 和 get 即可:
1)对于 set
2)对于 get
3)remove
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
3.内存泄漏
我们在上面可以看到:ThreadLocalMap 的 key---threadlocal 其实是一个弱引用。这会出现内存泄漏问题,但是内存泄漏不是因为弱引用,即使强引用也会出现问题:
强引用使用完 ThreadLocal ,thread Local Ref 被回收了,所以造成 threadLocal 无法被回收。
弱引用由于 ThreadLocalMap 只持有 ThreadLocal 的弱引用,没有任何强引用指向 threadlocal 实例, 所以 threadlocal 就可以顺利被 gc 回收,此时 Entry 中的 key=null,但是也会又内存泄漏,就是我们无法访问 value 这快地址了。
真实原因所以跟弱引用和强引用是没有关系的,原因为:1.没有手动删除这个 Entry2.CurrentThread 依然运行
对应的方法:1.使用完 ThreadLocal,调用其 remove 方法删除对应的 Entry2.使用完 ThreadLocal,当前 Thread 也随之运行结束(一般不可控!!!尤其当使用线程池的时候)
为什么用弱引用?既然强引用和弱引用都有问题,那为什么用弱引用?事实上,在 ThreadLocalMap 中的 set/getEntry 方法中,会对 key 为 null(也即是 ThreadLocal 为 null)进行判断,如果为 null 的话, 那么是会对 value 置为 null 的。
这就意味着使用完 ThreadLocal,CurrentThread 依然运行的前提下,就算忘记调用 remove 方法,弱引用比强引用可以多一层保障:弱引用的 ThreadLocal 会被回收,对应的 value 在下一次 ThreadLocalMap 调用 set,get,remove 中的任一方法的时候会被清除,从而避免内存泄漏。
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
版权声明: 本文为 InfoQ 作者【Studying_swz】的原创文章。
原文链接:【http://xie.infoq.cn/article/cf6cc5838f14b73a3c2879fdb】。文章转载请联系作者。
评论