文章目录
线程
线程的状态
- 就绪态 :
①该状态下的线程已经获得执行所需的所有资源,只要CPU分配执行权就能运行。
②所有就绪态的线程存放在就绪队列中。 - 运行态:
①获得CPU执行权,正在执行的线程。
②由于一个CPU同一时刻只能执行一条线程,因此每个CPU每个时刻只有一条运行态的线程。 - 阻塞态:
①当一条正在执行的线程请求某一资源失败时,就会进入阻塞态。
②而在Java中,阻塞态专指请求锁失败时进入的状态。
③由一个阻塞队列存放所有阻塞态的线程。
④处于阻塞态的线程会不断请求资源,一旦请求成功,就会进入就绪队列,等待执行。
PS:锁、IO、Socket等都是线程请求的资源。 - 等待态:
①当前线程中调用wait、join、park函数时,当前线程就会进入等待态。
②也有一个等待队列存放所有等待态的线程。
③线程处于等待态表示它需要等待其他线程的指示才能继续运行。
④进入等待态的线程会释放CPU执行权,并释放资源(如:锁) - 超时等待态:
①当运行中的线程调用sleep(time)、wait、join、parkNanos、parkUntil时,就会进入该状态;
②它和等待态一样,并不是因为请求不到资源,而是主动进入,并且进入后需要其他线程唤醒;
③进入该状态后释放CPU执行权 和 占有的资源。
④与等待态的区别:到了超时时间后自动进入阻塞队列,开始竞争锁。
6.终止态
线程执行结束后的状态。
线程状态变化(java.lang.Thread.State):
sleep()与yield() 比较:
sleep()可以设置休眠参数,可以低优先级的线程有执行的机会;
yield()只能给同等优先级的线程执行的机会,使当前线程进入就绪状态,执行的操作:先检测当前是否有相同优先级的线程处于同可运行状态,如有,则把CPU的占有权交给次线程,否则继续运行原来的线程,所以yield()方法称为“退让”,它把运行机会让给了同等级的其他线程。
wait()与sleep()比较:
1.不同点:
①wait()/notify()是Object的方法,sleep()是Thread的方法;
②sleep()不会释放锁资源,wait()会释放锁资源;
注意:
①wait()方法会释放CPU执行权和占有的锁。
②sleep(long)方法仅释放CPU使用权,锁仍然占用;线程被放入超时等待队列,与yield相比,它会使线程较长时间得不到运行。
③yield()方法仅释放CPU执行权,锁仍然占用,线程会被放入就绪队列,会在短时间内再次执行。
④wait和notify必须配套使用,即必须使用同一把锁调用;
⑤wait和notify必须放在一个同步块中调用;
⑥wait和notify的对象必须是他们所处同步块的锁对象。
join()方法底层是wait()方法实现的
https://blog.csdn.net/u010983881/article/details/80257703
线程的创建
- 实现Runnable接口
实现Runnable接口并实现run()方法,run()方法没有返回值,将Runnable的实例作为Thread的结构参数来创建线程实例,调用Thread的start()方法、ExecutorService的submit()方法、ExecutorService的execute()方法来启动运行线程;
public static void main(String[] args) throws ExecutionException, InterruptedException {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
int i = 0;
while (true) {
try {
Thread.sleep(20);
System.out.println(Thread.currentThread().getName() + " = " + i);
i++;
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}, "runnable Thread");
thread.start();
}
- 实现Callable接口
实现Callable接口并实现call()方法,call()方法有返回值,必须用ExecutorService的submit()方法来提交启动线程,可以用Future来接收线程执行完call()方法之后返回的值,当线程未执行完时,future.get()获取返回值时将会阻塞,直到线程执行完成;
public static ExecutorService executor = Executors.newFixedThreadPool(10);
public static void main(String[] args) throws ExecutionException, InterruptedException {
Callable<String> task = new Callable<String>() {
@Override
public String call() throws Exception {
int i = 0;
while (i < 100) {
Thread.sleep(100);
System.out.println("Thread Name = " + Thread.currentThread().getName() + i);
i++;
}
return "success";
}
};
Future<String> future = executor.submit(task);
System.out.println(" arrive time = " + new Date());
System.out.println(" run time = " + new Date() + " result = " + future.get());
executor.shutdown();
}
- 继承Thread类
线程Task类Task继承Thread类,并重写run()方法,创建Task类实例,并调用start()方法提交启动线程;
Thread类实现了Runnable接口,并包含Runnable类型的成员变量target,线程运行时,如果成员变量target不为空,调用target的run()方法,否则什么都不做,一般继承Thread的子类会重写run()方法;
public class Task extends Thread {
@Override
public void run() {
int i = 0;
while (true) {
try {
Thread.sleep(20);
System.out.println(Thread.currentThread().getName() + "=" + i);
i++;
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
public static void main(String[] args) {
new Task().start();
}
扩展:为什么Junit的测试方法中启动子线程时,子线程没有执行完就结束了??
实际上Junit是将test方法作为参数传递给了TestRunner的main函数,并通过main函数进行执行,如果test方法执行结束,即使还有其他的线程在运行,main函数都将调用System.exit(0);
System.exit()是系统调用,通知系统立即结束jvm的运行。其中System.exit()的参数是0,代表程序正常结束,如果参数是非0,代表程序异常结束;
摘自:https://blog.csdn.net/qq_40889460/article/details/101192003
线程池
IT领域中的"池化"思想一般表现为:统一管理IT资源,包括服务器、存储和网络资源等,通过共享资源,使用户在低投入中获益。
内存池(预先申请内存,提升申请内存速度,减少内存碎片);
连接池(预先申请数据库连接,提升申请连接的速度,降低系统的开销);
实例池(循环使用对象,减少资源在初始化和释放时的昂贵损耗)
ThreadPoolExecutor类
//使用原子类Integer来存放线程池状态和线程数量,其中高3位表示线程池状态,其余低位(一般29位)表示线程数量
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
//表示线程数量的位数
private static final int COUNT_BITS = Integer.SIZE - 3;
//最大的线程数量
private static final int CAPACITY = (1 << COUNT_BITS) - 1;
// runState is stored in the high-order bits
//运行中:可以接受新提交的任务,也能处理阻塞队列中的任务;
private static final int RUNNING = -1 << COUNT_BITS;
//关闭:不接受新提交的任务,但能处理阻塞队列中的任务;
private static final int SHUTDOWN = 0 << COUNT_BITS;
//停止:不接受新提交的任务,不处理阻塞队列中的任务,尝试停止运行中的任务;
private static final int STOP = 1 << COUNT_BITS;
//终止:所有任务已经终止,线程数量为0,线程关闭后会调用terminated()方法
private static final int TIDYING = 2 << COUNT_BITS;
//结束:在执行terminated()方法后,线程池会变成结束状态
private static final int TERMINATED = 3 << COUNT_BITS;
// Packing and unpacking ctl
//通过位运算来获取线程池状态和线程数量
private static int runStateOf(int c) { return c & ~CAPACITY; }
private static int workerCountOf(int c) { return c & CAPACITY; }
private static int ctlOf(int rs, int wc) { return rs | wc; }
//任务缓冲队列
private final BlockingQueue<Runnable> workQueue;
/**
* Lock held on access to workers set and related bookkeeping.
* While we could use a concurrent set of some sort, it turns out
* to be generally preferable to use a lock. Among the reasons is
* that this serializes interruptIdleWorkers, which avoids
* unnecessary interrupt storms, especially during shutdown.
* Otherwise exiting threads would concurrently interrupt those
* that have not yet interrupted. It also simplifies some of the
* associated statistics bookkeeping of largestPoolSize etc. We
* also hold mainLock on shutdown and shutdownNow, for the sake of
* ensuring workers set is stable while separately checking
* permission to interrupt and actually interrupting.
*/
//从任务线程池中获取线程时的锁
private final ReentrantLock mainLock = new ReentrantLock();
/**
* Set containing all worker threads in pool. Accessed only when
* holding mainLock.
*/
//存放执行任务的线程池
private final HashSet<Worker> workers = new HashSet<Worker>();
//corePoolSize:线程池核心线程数量
//maximumPoolSize:线程池最大线程数量
//keepAliveTime:线程数量在超过核心线程数量时,空闲线程等待新任务的最大等待时间
//unit:keepAliveTime的等待时间-单位
//workQueue:线程池的任务缓冲队列
//threadFactory:线程池创建线程池的工厂类
//handler:当提交任务时,到达线程界限或者缓存队列数量极限时的拒绝策略
//**构造参数**
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler) {
if (corePoolSize < 0 ||
maximumPoolSize <= 0 ||
maximumPoolSize < corePoolSize ||
keepAliveTime < 0)
throw new IllegalArgumentException();
if (workQueue == null || threadFactory == null || handler == null)
throw new NullPointerException();
this.acc = System.getSecurityManager() == null ?
null :
AccessController.getContext();
this.corePoolSize = corePoolSize;
this.maximumPoolSize = maximumPoolSize;
this.workQueue = workQueue;
this.keepAliveTime = unit.toNanos(keepAliveTime);
this.threadFactory = threadFactory;
this.handler = handler;
}
线程池策略:
AbortPolicy:默认策略,直接跑出异常阻止系统正常运行
CallerRunsPolicy:该策略既不会抛弃任务,也不会抛出异常,而是将任务回馈至发起方比如main线程
DiscardOldestPolicy:抛弃队列中等待最久的任务,然后把当前任务加入队列中尝试再次提交当前任务
DiscardPolicy:直接丢弃任务,不给予任何处理也不跑出异常,如果允许任务丢失,这是最好的一种方案
常用的线程池类型:
//java.util.concurrent.Executors
//创建一个固定线程数量,线程不会回收的线程池
public static ExecutorService newFixedThreadPool(int nThreads, ThreadFactory threadFactory) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>(),
threadFactory);
}
//创建一个单线程的线程执行器
public static ExecutorService newSingleThreadExecutor(ThreadFactory threadFactory) {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>(),
threadFactory));
}
//创建一个线程数量上限(实际数量上限是Integer支持的最大值),但是线程池中的线程都可以自动回收的线程池
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>());
}
//创建一个固定线程数量,可以延迟执行任务的线程池
public static ScheduledExecutorService newScheduledThreadPool(
int corePoolSize, ThreadFactory threadFactory) {
return new ScheduledThreadPoolExecutor(corePoolSize, threadFactory);
}
线程池内部运行机制:
public void execute(Runnable command) {
if (command == null)
throw new NullPointerException();
/*
* clt记录着runState和workerCount
*/
int c = ctl.get();
/*
* workerCountOf方法取出低29位的值,表示当前活动的线程数;
* 如果当前活动线程数小于corePoolSize,则新建一个线程放入线程池中;
* 并把任务添加到该线程中。
*/
if (workerCountOf(c) < corePoolSize) {
/*
* addWorker中的第二个参数表示限制添加线程的数量是根据corePoolSize来判断还是maximumPoolSize来判断;
* 如果为true,根据corePoolSize来判断;
* 如果为false,则根据maximumPoolSize来判断
*/
if (addWorker(command, true))
return;
/*
* 如果添加失败,则重新获取ctl值
*/
c = ctl.get();
}
/*
* 如果当前线程池是运行状态并且任务添加到队列成功
*/
if (isRunning(c) && workQueue.offer(command)) {
// 重新获取ctl值
int recheck = ctl.get();
// 再次判断线程池的运行状态,如果不是运行状态,由于之前已经把command添加到workQueue中了,
// 这时需要移除该command
// 执行过后通过handler使用拒绝策略对该任务进行处理,整个方法返回
if (! isRunning(recheck) && remove(command))
reject(command);
/*
* 获取线程池中的有效线程数,如果数量是0,则执行addWorker方法
* 这里传入的参数表示:
* 1. 第一个参数为null,表示在线程池中创建一个线程,但不去启动;
* 2. 第二个参数为false,将线程池的有限线程数量的上限设置为maximumPoolSize,添加线程时根据maximumPoolSize来判断;
* 如果判断workerCount大于0,则直接返回,在workQueue中新增的command会在将来的某个时刻被执行。
*/
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
}
/*
* 如果执行到这里,有两种情况:
* 1. 线程池已经不是RUNNING状态;
* 2. 线程池是RUNNING状态,但workerCount >= corePoolSize并且workQueue已满。
* 这时,再次调用addWorker方法,但第二个参数传入为false,将线程池的有限线程数量的上限设置为maximumPoolSize;
* 如果失败则拒绝该任务
*/
else if (!addWorker(command, false))
reject(command);
}
如果workerCount < corePoolSize,则创建并启动一个线程来执行新提交的任务;
如果workerCount >= corePoolSize,且线程池内的阻塞队列未满,则将任务添加到该阻塞队列中;
如果workerCount >= corePoolSize && workerCount < maximumPoolSize,且线程池内的阻塞队列已满,则创建并启动一个线程来执行新提交的任务;
如果workerCount >= maximumPoolSize,并且线程池内的阻塞队列已满, 则根据拒绝策略来处理该任务, 默认的处理方式是直接抛异常。
线程池状态的变化:
RUNNING -> SHUTDOWN:调用shutdown()方法,其中finalize()方法也会内部调用shutdown()方法;
(RUNNING or SHUTDOWN) -> STOP:调用shutdownNow()方法;
SHUTDOWN -> TIDYING:当阻塞队列和线程池的任务都没有了;
STOP -> TIDYING:线程池空了;
TIDYING -> TERMINATED:当terminated()方法执行完之后;
线程池的优点:
- 降低资源消耗:在平常的多线程场景下,频繁创建/销毁线程,将带来额外的消耗,可能会非常巨大,通过线程池重复利用已创建的线程,降低其损耗;
- 提高响应速度:在任务抵达时,无需等待线程创建即可立即执行;
- 提高线程的可管理性:线程是稀缺的系统资源,一方面如果无限的申请创建,会消耗系统资源,引发系统资源耗尽的风险;另一方面因为线程的不合理分布,系统无法合理管理内部资源分布,导致降低系统的稳定性;
- 提供更多更强大的功能:线程池具备可拓展性,运行开发人员向其中增加更多功能,例如:延迟定时线程池(允许任务延期执行或者定期执行)
线程安全
在并发编程中存在线程安全问题,主要原因有:
- 多线程之间存在共享数据;
- 多线程共同操作共享数据;
多线程运行时,每个访问临界共享数据的方法都必须被同步,否在程序就不会正常的运行;
Brian同步规则:如果你正在写一个变量,它可能接下来将被另一个线程读取,或者正在读取一个上一次已经被另一个线程写过的变量,那么你必须使用同步,并且读写线程都必须用相同的监视器锁同步。
关键字synchronized
synchronized可以修饰代码块、方法,可以保证方法或者代码块在运行时,同一时刻只有一个方法可以进入到临界区,同时它还可以保证共享变量的内存可见性;
特点:使用简单,由JVM提供,锁的释放不用人工干预,由JVM释放,降低了死锁的可能性;
缺点:无法使用锁的高级功能,如读写锁等,使用不灵活,不能获取线程获取锁的状态,锁无法被中断;
- 修饰代码块时,锁对象obj可以被指定为:this(当前对象实例)、xxx.class(某个类)、某个类的实例对象;
- 修饰类的普通方法时,锁对象是当前类实例对象,等同于this;
- 修饰类的静态方法时,锁对象是当前类的class对象 ;
synchronized (obj) {
//同步代码块
}
- 在定义接口方法时不能使用synchronized关键字;
- 构造方法不能使用synchronized关键字,但可以使用synchronized代码块来进行同步;
- synchronized 关键字不能被继承 。如果子类覆盖了父类的被 synchronized关键字修饰的方法,子类的该方法只要没有synchronized 关键字,那么就默认没有同步,也就是说不能继承父类方法的 synchronized。
线程执行进入synchronized修饰的临界区之前,要获取锁对象的对象头中监视器锁monitor(JVM的每个对象头部有一个监视器锁monitor);
参考资料:synchronized底层原理:https://www.yunqishi.net/dnjc/dnzx/30175.html
只有线程拥有某个对象的独占锁时,才能够调用该对象的notify()/wait()/notifyAll()方法,这三个方法也是也依赖对象头的监视器锁monitor实现的,所以存在于Object对象中;
接口Lock
特点:使用灵活,可以实现读写锁、公平锁,锁可以被中断,线程可以知道获取锁的状态;
缺点:需要手动调用unLock()方法释放锁,使用不当可能造成死锁;
Lock主要的接口方法:
// 获取锁 ,如果锁已被其他线程获取,则进行等待。
void lock()
// 如果当前线程未被中断,则获取锁,可以响应中断
void lockInterruptibly()
// 仅在调用时锁为空闲状态才获取该锁:该方法是有返回值的,它表示用来尝试获取锁,如果获取成功,则返回true;如果获取失败(即锁已被其他线程获取),则返回false,也就是说这个方法无论如何都会立即返回;
boolean tryLock()
// 如果锁在给定的等待时间内空闲,并且当前线程未被中断,则获取锁
boolean tryLock(long time, TimeUnit unit)
// 释放锁
void unlock()
中断操作:interrupt()方法只能中断阻塞过程中的线程而不能中断正在运行过程中的线程
ReentrantLock
ReentrantLock是实现了Lock接口的可重入锁;
public class CountTask implements Runnable {
public static CountDownLatch countDownLatch;
private static Lock lock = new ReentrantLock();
public void countNum() throws InterruptedException {
lock.lock();
try {
for(int i= 0;i<200;i++){
num ++;
Thread.sleep(10);
}
countDownLatch.countDown();
}finally {
lock.unlock();
}
}
public static void print() throws InterruptedException {
countDownLatch.await();
System.out.println("num = " + num);
}
}
@Test
public void testLock0() throws InterruptedException {
CountTask countTask = new CountTask();
CountTask.countDownLatch = new CountDownLatch(2);
new Thread(() -> {
try {
countTask.countNum();
} catch (InterruptedException e) {
e.printStackTrace();
}
}).start();
new Thread(() -> {
try {
countTask.countNum();
} catch (InterruptedException e) {
e.printStackTrace();
}
}).start();
CountTask.countDownLatch.await();
CountTask.print();
}
ReentrantReadWriteLock(读写锁)
包含两个成员变量:WriteLock、ReadLock(均实现Lock接口),通过CAS操作对占有锁的读写线程数进行计数,来实现读锁并发,写锁独占;
读写锁实现原理参考资料:https://blog.csdn.net/chenzihao36/article/details/106947043
public class CountTask implements Runnable {
private ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
public static int num = 0;
public void read() {
readWriteLock.readLock().lock();
try {
System.out.println("ready to be read = " + Thread.currentThread().getName());
Thread.sleep(100);
System.out.println("has read date " + num + " " + Thread.currentThread().getName());
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
readWriteLock.readLock().unlock();
}
}
public void write() {
readWriteLock.writeLock().lock();
try {
System.out.println("ready to write = " + Thread.currentThread().getName());
Thread.sleep(100);
num = num + 1;
System.out.println("has write date " + num + " " + Thread.currentThread().getName());
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
readWriteLock.writeLock().unlock();
}
}
@Test
public void testLock() throws InterruptedException {
CountTask countTask = new CountTask();
for (int i = 0; i < 3; i++) {
new Thread(() -> {
while (true) {
countTask.read();
Thread.yield();
}
},"readThread"+i).start();
new Thread(() -> {
while (true) {
countTask.write();
Thread.yield();
}
},"writeThread"+i).start();
}
Thread.sleep(Integer.MAX_VALUE);
}
}
关键字volatile
1.保证变量的可见性;
当一个线程修改volatile变量时,立刻将最新的值同步到主内存中;当一个线程要读取volatile变量时,直接从主内存中读取最新的值,跳过CPU cache;
CPU缓存导致数据的不可见性:JVM是多线程的环境,多个线程在实际运行的时候,有可能是在不同的CPU核心中运行的,每个线程是先将主内存的数据拷贝到CPU cache中,所以每一个线程在读取内存的数据的时候,也有可能是读取的线程内部的缓存,这个时候,假如其他某个线程修改了这个变量,对于这线程来说是不知情的,也就是不可见的;
2.禁止指令重排序优化;
有volatile修饰的变量,赋值后多执行了一个“load addl $0x0, (%esp)”操作,这个操作相当于一个内存屏障,只有一个CPU访问内存时,并不需要内存屏障;
指令重排序:在执行程序时,为了提高性能,编译器和处理器会对指令做重排序(是指CPU采用了允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理)。
- 编译器优化重排序:编译器在不改变单线程程序语义的前提下,可以重新安排语句的执行顺序。
- 指令级并行的重排序:如果不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序。
- 内存系统的重排序:处理器使用缓存和读写缓冲区,这使得加载和存储操作看上去可能是在乱序执行。
内存屏障(Memory Barrier):又称内存栅栏,是一个CPU指令,基本上它是一条这样的指令:
- 保证特定操作的执行顺序:插入一条Memory Barrier会告诉编译器和CPU,不管什么指令都不能和这条Memory Barrier指令重排序
- 影响某些数据(或则是某条指令的执行结果)的内存可见性:强制刷出各种CPU cache,如一个Write-Barrier(写入屏障)将刷出所有在Barrier之前写入 cache 的数据,因此,任何CPU上的线程都能读取到这些数据的最新版本。
as-if-serial语义:不管怎么重排序,单线程下的执行结果不能被改变,编译器、runtime和处理器都必须遵守as-if-serial语义。
数据依赖性:如果两个操作访问同一个变量,其中一个为写操作,此时这两个操作之间存在数据依赖性;编译器和处理器不会改变存在数据依赖性关系的两个操作的执行顺序,即不会重排序。
与线程并发有关的内存特性
- 可见性:是指线程之间的可见性,一个线程修改的状态对另一个线程是可见的。
Java 中 volatile、synchronized 和 final 实现可见性。- 原子性:原子是世界上的最小单位,具有不可分割性。 操作是不可分割的,那么我们说这个操作是原子操作,非原子操作都会存在线程安全问题,在 Java 中 synchronized 和在 lock、unlock 中操作保证原子性。
原子类:java的concurrent包下提供了一些原子类:AtomicInteger、AtomicLong、AtomicReference- 有序性:Java 语言提供了 volatile 和 synchronized 两个关键字来保证线程之间操作的有序性,volatile 是因为其本身包含“禁止指令重排序”的语义,synchronized 是由“一个变量在同一个时刻只允许一条线程对其进行 lock 操作”这条规则获得的,此规则决定了持有同一个对象锁的两个同步块只能串行执行。
循环CAS操作和Unsafe类
CAS(Compare and Swap)操作:三个参数,一个当前内存值V、旧的预期值A、即将更新的值B,当且仅当预期值A和内存值V相同时,将内存值修改为B并返回true,否则什么都不做,并返回false。
循环CAS实现线程安全的基本思路:循环进行CAS操作直到成功为止;
CAS操作存在ABA问题:线程1获取的内存区域的值"A"进行之后的CAS,但是在线程1获取值之后,其他线程将该内存区域的值通过CAS操作先由"A"变为"B",然后由"B"变成"A",然后线程1进行CAS操作是可以成功,但是这个过程实际是存在问题,该内存的值实际已经发生过改变;
AtomicStampedReference来解决ABA问题:这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用,并且当前标志是否等于预期标志,如果全部相等,则以原子方式将该引用和该标志的值设置为给定的更新值。
应用:
- java的concurrent包下提供了一些原子类:AtomicInteger、AtomicLong、AtomicReference,均是使用了volatile和CAS操作保证数据在多线程运行时的安全修改;
- 线程池的任务调度管理中,线程数量和线程池状态变量cli的修改也是使用循环CAS操作实现了线程安全;
- ConcurrentHashMap中使用了sizeCtl记录数组的长度(邻接链表的数组);
- Lock实现的QAS实现中使用了CAS来处理记录竞争锁的线程数量字段;
Unsafe类
JAVA没有方法能访问底层系统,因此需要本地方法来做,Unsafe就是被提供来直接操作内存中的数据的类。
Unsafe是通过"饿汉模式"的单例模式进行创建的,同时只有主类加载器(BootStrap classLoader)加载的类才能获取Unsafe的实例;
//Unsafe提供的获取Unsafe类实例的静态方法
@CallerSensitive
public static Unsafe getUnsafe() {
//通过Reflection的getCallerClass判断当前调用的类是否是主类加载器(BootStrap classLoader)加载的
Class var0 = Reflection.getCallerClass();
if (!VM.isSystemDomainLoader(var0.getClassLoader())) {
throw new SecurityException("Unsafe");
} else {
return theUnsafe;
}
}
CAS机制主要涉及的native方法:
public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);
Unsafe类的方法主要作用:
(1)初始化操作
(2)操作对象属性
(3)操作数组元素
(4)线程挂起和回复
(5)CAS机制
参考资料:
- https://baijiahao.baidu.com/s?id=1648712942552745701&wfr=spider&for=pc
- https://www.jianshu.com/p/d4551df6e6b8
synchronized和循环+CAS
- 资源竞争比较少时,使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态切换操作额外消耗cpu资源;CAS基于硬件(内存操作)实现,不需要销切换线程,操作自旋的概率较低,可以获得更高的性能;
- 资源竞争比较多时,CAS自旋概率比较大,会浪费更多的CPU资源,效率反而低于synchronized;
循环+CAS乐观锁:比较适用于读多写少的场景,并且并发线程冲突比较少的场景;
Lock中也是使用了循环+CAS机制
synchronized悲观锁:适用于强一致性的场景,但是效率比较低,特别是读并发比较低;
锁的特性对比
可重入锁:以线程为单位,当一个线程获取对象锁之后,这个线程可以再次获取本对象上的锁,而其他的线程是不可以的.(同一个加锁的线程,自己调用自己不会发生死锁情况)
-原理:每个锁都关联一个请求计数和和占有锁的线程,当请求计数为 0 时,认为锁是未被占有的;当线程请求未占有的锁时,jvm会记录锁的占有者,并使得计数为1,如果同一个线程再次请求这个锁,计数将递增;每次占用线程退出同步块,计数器值将递减,直到计数器为0,锁被释放;在此过程中,其他要获取该锁对象进入临界区的线程会被阻塞;
可中断锁:可中断锁就是可以响应中断的锁,如果某一线程A正在执行锁中的代码,另一线程B正在等待获取该锁,可能由于等待时间过长,线程B不想等待了,想先处理其他事情,我们可以让它中断自己或者在别的线程中中断它,这种就是可中断锁。在前面演示tryLock(long time, TimeUnit unit)和lockInterruptibly()的用法时已经体现了Lock的可中断性。
公平锁:尽量以请求锁的顺序来获取锁。例如:同是有多个线程在等待一个锁,当这个锁被释放时,等待时间最久的线程(最先请求的线程)会获得该所,这种就是公平锁。而非公平锁则无法保证锁的获取是按照请求锁的顺序进行的,这样就可能导致某个或者一些线程永远获取不到锁。
悲观锁: 假定共享资源在多个线程修改时,会发生并发冲突,即共享资源会被某个线程更改;所以当某个线程获取共享资源时,会阻止别的线程获取共享资源,也称独占锁或者互斥锁,例如java中的synchronized同步锁。
乐观锁: 假设共享资源在多个线程修改时,不会发生并发冲突,只有在最后更新共享资源的时候会判断一下在此期间有没有别的线程修改了这个共享资源;如果发生冲突就重试,直到没有冲突,更新成功,例如CAS就是一种乐观锁实现方式。
synchronized | ReentrantLock | ReentrantReadWriteLock | |
---|---|---|---|
可重入锁 | 是 | 是 | 是 |
可中断锁 | 否 | 是 | 是 |
公平锁 | 否 | 默认不是,支持公平锁 | 默认不是,支持公平锁 |
读写锁 | 否 | 否 | 支持读并发,写独占 |
扩展
CountDownLatch类(线程计数器)
@Test
public void testRunnable() throws InterruptedException {
//参数count为计数器初始值
CountDownLatch countDownLatch = new CountDownLatch(1);
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
int i = 0;
while (i < 100) {
try {
Thread.sleep(20);
System.out.println(Thread.currentThread().getName() + " = " + i);
i++;
} catch (InterruptedException e) {
e.printStackTrace();
}
}
//将count值减1
countDownLatch.countDown();
}
}, "runnable Thread");
thread.start();
//调用await()方法的线程会被挂起,它会等待直到count值为0才继续执行
countDownLatch.await();
}
ThreadLocal类
ThreadLocal类:存在一个静态内部类ThreadLocalMap(ThreadLocalMap是一个包私有的类,目前仅在Thread类中声明引用)、threadLocalHashCode(当前ThreadLocal实例的hash码),其成员方法均是在操作ThreadLocalMap;
ThreadLocalMap类:在Thread类中被声明引用的局部成员变量,包含一个Entry[]成员变量table,根据ThreadLocal实例的hash码取模之后,存放值于table对应的数组节点中;
ThreadLocalMap<ThreadLocal, Object>的弱引用可能存在的内存泄漏问题:当线程没有结束时,ThreadLocal已经被回收,则可能导致ThreadLocalMap中存在null->Object 的值,造成内存泄漏
处理方式:①使用完ThreadLocalMap后,调用remove方法清除线程共享变量;②将ThreadLocal定义为private static类型,这样就弱引用问题就不存在了;
public class TestThreadLocal {
private static final ThreadLocal<Object> threadLocal = new ThreadLocal<Object>() {
/**
* ThreadLocal没有被当前线程赋值时或当前线程刚调用remove方法后调用get方法,返回此方法值
*/
@Override
protected Object initialValue() {
System.out.println(Thread.currentThread().getName() + " threadLocalMap 未初始化,调用初始化方法进行初始化");
return null;
}
};
public static void main(String[] args) {
new Task("Thread A").start();
new Task("Thread B").start();
}
static class Task extends Thread {
public Task(String name){
super(name);
}
@Override
public void run() {
for (int i = 0; i < 10; i++) {
try {
System.out.println(Thread.currentThread().getName() + " 获取线程本地变量的值 = " + TestThreadLocal.threadLocal.get());
Thread.sleep(1000);
TestThreadLocal.threadLocal.set(Thread.currentThread().getName() + i);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
}