话不多说,先上图。
欲说线程,必先说进程。
操作系统在分配资源时是把资源分配给进程的, 但是 CPU 资源比较特殊,它是被分配到线程的,因为真正要占用CPU运行的是线程,所以也说线程是 CPU分配的基本单位。
在Java中,当我们启动 main 函数其实就启动了一个JVM进程,而 main 函数在的线程就是这个进程中的一个线程,也称主线程。
示意图如下:
一个进程中有多个线程,多个线程共用进程的堆和方法区资源,但是每个线程有自己的程序计数器和栈。
Java中创建线程有三种方式,分别为继承Thread类、实现Runnable接口、实现Callable接口。
public class ThreadTest { /** * 继承Thread类 */ public static class MyThread extends Thread { @Override public void run() { System.out.println("This is child thread"); } } public static void main(String[] args) { MyThread thread = new MyThread(); thread.start(); } }
public class RunnableTask implements Runnable { public void run() { System.out.println("Runnable!"); } public static void main(String[] args) { RunnableTask task = new RunnableTask(); new Thread(task).start(); } }
上面两种都没有返回值。
public class CallerTask implements Callable<String> { public String call() throws Exception { return "Hello,i am running!"; } public static void main(String[] args) { //创建异步任务 FutureTask<String> task=new FutureTask<String>(new CallerTask()); //启动线程 new Thread(task).start(); try { //等待执行完成,并获取返回结果 String result=task.get(); System.out.println(result); } catch (InterruptedException e) { e.printStackTrace(); } catch (ExecutionException e) { e.printStackTrace(); } } }
在Object类中有一些函数可以用于线程的等待与通知。
notify()
或者 notifyAll()
方法;(2)其他线程调用了该线程 interrupt()
方法,该线程抛出InterruptedException异常返回。timeout ms
时间内被其它线程调用该共享变量的notify()
或者 notifyAll()
方法唤醒,那么该函数还是会因为超时而返回。wait(long timout)
函数。上面是线程等待的方法,而唤醒线程主要是下面两个方法:
如果有这样的场景,需要等待某几件事情完成后才能继续往下执行,比如多个线程加载资源,需要等待多个线程全部加载完毕再汇总处理。Thread类中有一个join方法可实现。
Thread类中有一个静态态的 sleep 方法,当一个个执行中的线程调用了Thread 的sleep方法后,调用线程会暂时让出指定时间的执行权,也就是在这期间不参与 CPU 的调度,但是该线程所拥有的监视器资源,比如锁还是持有不让出的。指定的睡眠时间到了后该函数会正常返回,线程就处于就绪状态,然后参与 CPU 的调度,获取到 CPU 资源后就可以继续运行。
Thread 有一个静态 yield 方法,当一个线程调用 yield 方法时,实际就是在暗示线程调度器当前线程请求让出自己的CPU 使用,但是线程调度器可以无条件忽略这个暗示。
当一个线程调用 yield 方法时, 当前线程会让出 CPU 使用权,然后处于就绪状态,线程调度器会从线程就绪队列里面获取一个线程优先级最高的线程,当然也有可能会调度到刚刚让出 CPU 的那个线程来获取 CPU 行权。
Java 中的线程中断是一种线程间的协作模式,通过设置线程的中断标志并不能直接终止该线程的执行,而是被中断的线程根据中断状态自行处理。
上面整理了线程的创建方式和一些常用方法,可以用线程的生命周期把这些方法串联起来。
在Java中,线程共有六种状态:
线程在自身的生命周期中, 并不是固定地处于某个状态,而是随着代码的执行在不同的状态之间进行切换,Java线程状态变化如图示:
使用多线程的目的是为了充分利用CPU,但要认识到,每个CPU同一时刻只能被一个线程使用。
为了让用户感觉多个线程是在同时执行的, CPU 资源的分配采用了时间片轮转也就是给每个线程分配一个时间片,线程在时间片内占用 CPU 执行任务。当线程使用完时间片后,就会处于就绪状态并让出 CPU 让其他线程占用,这就是上下文切换。
死锁是指两个或两个以上的线程在执行过程中,因争夺资源而造成的互相等待的现象,在无外力作用的情况下,这些线程会一直相互等待而无法继续运行下去。
那么为什么会产生死锁呢? 死锁的产生必须具备以下四个条件:
该如何避免死锁呢?答案是至少破坏死锁发生的一个条件。
其中,互斥这个条件我们没有办法破坏,因为用锁为的就是互斥。不过其他三个条件都是有办法破坏掉的,到底如何做呢?
Java中的线程分为两类,分别为 **daemon 线程(守护线程)**和 user 线程(用户线程)。
在JVM 启动时会调用 main 函数,main函数所在的线程就是一个用户线程。其实在 JVM 内部同时还启动了很多守护线程, 比如垃圾回收线程。
那么守护线程和用户线程有什么区别呢?区别之一是当最后一个非守护线程束时, JVM会正常退出,而不管当前是否存在守护线程,也就是说守护线程是否结束并不影响 JVM退出。换而言之,只要有一个用户线程还没结束,正常情况下JVM就不会退出。
ThreadLocal是JDK 包提供的,它提供了线程本地变量,也就是如果你创建了ThreadLocal ,那么访问这个变量的每个线程都会有这个变量的一个本地副本,当多个线程操作这个变量时,实际操作的是自己本地内存里面的变量,从而避免了线程安全问题。创建 ThreadLocal 变量后,每个线程都会复制 到自己的本地内存。
可以通过set(T)方法来设置一个值,在当前线程下再通过get()方法获取到原先设置的值。
下面来看一个ThreadLocal的使用实例:
public class ThreadLocalTest { //创建ThreadLocal变量 static ThreadLocal<String> localVar = new ThreadLocal<String>(); //打印函数 static void print(String str) { //打印当前线程本地内存中localVar变量值 System.out.println(str + ":" + localVar.get()); //清除前线程本地内存中localVar变量值 //localVar.remove(); } public static void main(String[] args) { Thread thread1 = new Thread(new Runnable() { public void run() { //设置线程1中本地变量localVal的值 localVar.set("线程1的值"); //调用打印函数 print("线程1"); //打印本地变量的值 System.out.println("线程1打印本地变量后:" + localVar.get()); } }); Thread thread2 = new Thread(new Runnable() { public void run() { //设置线程2中本地变量localVal的值 localVar.set("线程2的值"); //调用打印函数 print("线程2"); //打印本地变量的值 System.out.println("线程2打印本地变量后:" + localVar.get()); } }); thread1.start(); thread2.start(); } }
在Java中,所有实例域、静态域和数组元素都存储在堆内存中,堆内存在线程之间共享 。
Java线程之间的通信由Java内存模型控制,Java内存模型决定一个线程对共享变量的写入何时对另一个线程可见。
从抽象的角度来看,Java内存模型定义了线程和主内存之间的抽象关系:线程之间的共享变量存储在主内存(Main Memory)中,每个线程都有一个私有的本地内存(Local Memory),本地内存中存储了该线程以读/写共享变量的副本。本地内存是Java内存模型的 一个抽象概念,并不真实存在。它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。
Java内存模型的抽象示意如图:
在实际实现中线程的工作内存如下图:
synchronized ****块是 Java 提供的一种原子性内置锁, Java中的每个对象都可以把它当作同步锁来使用,这些 Java内置的使用者看不到的锁被称为内部锁,也作监视器锁。
线程的执行代码在进入 synchronized 代码块前会自动获取内部锁,这时候其他线程访问该同步代码块 被阻塞挂起。拿到内部锁的线程会在正常退出同步代码块或者抛出异常后或者在同步块调用了该内置锁资源 wait系列方法时释放该内置锁。内置锁是排它锁,就是当一个线程获取这个锁后,其他线程必须等待该线程释放锁后才能获取该锁。
synchronized 的内存语义:这个内存语义就可以解决共享变量内存可见性问题,进入synchronized 块的内存语义是把在synchronized 块内使用到的变量从线程的工作内存中清除,这样在 synchronized 块内使用到该变量时就不会从线程的工作内存中获取,而是直接从主内存中获取。 退出 synchronized 块的内存语义是把在 synchronized 块内对共享变修改刷新到主内存。
上面介绍了使用锁的方式可以解决共享内存可见性问题,但是使用锁太笨重,因为它会带来线程上下文的切换开销,对于解决内存可见性问题, Java 还提供了volatile种弱形式的同步,也就是使用 volatile 关键字, 该关键字可以确保对一个变量的更新对其他线程马上可见。
当一个变量被声明为volatile时,线程在写入变量时不会把值缓存在寄存器或者其他地方,而是会把值刷新回主内存,当其它线程读取该共享变量,会从主内存重新获取最新值,而不是使用当前线程的工作内存中的值。
volatile虽然提供了可见性保证,但并不保证操作的原子性。
所谓原子性操作,是指执行一系列操作时,这些操作要么全部执行,要么全部不执行,不存在只执行其中一部分的情况。
例如在设计计数器一般都先读取当前值,然后+1,再更新。这个过程是读-改-写的过程,如果不能保证这个过程是原子性的,那么就会出现线程安问题。
那么如何才能保证多个操作的原子性呢?最简单的方法就是使用 synchronized 关键字进行同步。还可以用CAS操作。从Java 1.5开始,JDK的并发包里也提供了一些类来支持原子操作。
synchronized 是独占锁,没有获取内部锁的线程会被阻塞掉,大大降级了并发性。
在Java中, 锁在并发处理中占据了一席之地,但是使用锁有有个不好的地方,就是当线程没有获取到锁时会被阻塞挂起,这会导致线程上下文的切换和重新调度开销。
Java 提供了非阻塞的 volatile 关键字来解决共享变量的可见性问题,这在一定程度上弥补了锁带来的开销问题,但是 volatile 只能保 共享变量可见性,不能解决读-改-写等的原子性问题。
CAS即 Compre and Swap ,其是 JDK 提供的非阻塞原子性操作,它通过硬件保证了比较-更新操作的原子性。JDK 里面的 Unsafe 类提供了一系列的compareAndSwap *方法,以 compareAndSwapLong 方法为例,看一下什么是CAS操作。
CAS有个经典的ABA问题。因为CAS需要在操作值的时候,检查值有没有发生变化,如果没有发生变化,则更新,但是如果一个值原来是A,变成了B,又变成了A,那么使用CAS进行检查时会发现它 的值没有发生变化,但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号,每次变量更新的时候把版本号加1,那么A→B→A就会变成1A→2B→3A。
乐观锁和悲观锁是在数据库中引入的名词,但是在并发包锁里面引入了类似的思想。
悲观锁指对数据被外界修改持保守态度,认为数据很容易就会被其他线程修改,所以在数据被处理前先对数据进行加锁,并在整个数据处理过程中,使数据处于锁定状态。悲观锁的实现往往依靠数据库提供的锁机制,即在数据 ,在对数据记录操作前给记录排它锁。如果获取锁失败, 则说明数据正在被其它线程修改,当前线程则等待或者抛出异常。 如果获取锁成功,则对记录进行操作 ,然后提交事务后释放排它锁。
乐观锁相对悲观锁来说的,它认为数据在一般情况下不会造成冲突,所以在访问记录前不会加排它锁,而在进行数据提交更新时,才会正式对数据冲 与否进行检测 。具体来说,根据 update 返回的行数让用户决定如何去做 。
根据线程获取锁的抢占机制,锁可以分为公平锁和非公平锁,公平锁表示线程获取锁的顺序是按照线程请求锁的时间早晚来决定的,也就是最早请求锁的线程将最早获取到锁。
而非公平锁是在运行时闯入,也就是先来不一定先得。
ReentrantLock 提供了公平锁和非公平锁的实现:
例如,假设线程A已经持有了锁,这时候线程B请求该锁其将被挂起 。当线程A释放锁后,假如当前有线程C也需要取该锁,如果采用非公平锁式,则根据线程调度策略 ,线程B和线程C两者之一可能获取锁,这时候不需要任何其他干涉,而如果使用公平锁则需要把C挂起,让B获取当前锁。
在没有公平性需求的前提下尽量使用非公平锁,因为公平锁会带来性能开销。
根据锁只能被单个线程持有还是能被多个线程共同持有,锁可以分为独占锁和共享锁。
独占锁保证任何时候都只有一个线程能得到锁, ReentrantLock 就是以独占方式实现的。
共享锁则可以同时由多个线程持有 ,例如 ReadWriteLock读写锁,它允许一个资源可以被多线程同时进行读操作。
独占锁是一种悲观锁,共享锁是一种乐观锁。
当一个线程要获取一个被其他线程持有的独占锁时,该线程会被阻塞。
那么当 一个线程再次获取它自己己经获取的锁时是否会被阻塞呢?如果不被阻塞,那么我们说该锁是可重入的,也就是只要该线程获取了该锁,那么可以无限次数(严格来说是有限次数)地进入被该锁锁住的代码。
由于 Java 中的线程是与操作系统中的线程 一一对应的,所以当一个线程在获取锁(比如独占锁)失败后,会被切换到内核状态而被挂起 。当该线程获取到锁时又需要将其切换到内核状态而唤醒该线程。而从用户状态切换到内核状态的开销是比较大的,在一定程度上会影响并发性能。
自旋锁则是,当前线程在获取锁时,如果发现锁已经被其他线程占有,它不马上阻塞自己,在不放弃 CPU 使用权的情况下,多次尝试获取(默认次数是 10 ,可以使用 -XX:PreBlockSpinsh
参数设置该值),很有可能在后面几次尝试中其他线程己经释放了锁,如果尝试指定的次数后仍没有获取到锁则当前线程才会被阻塞挂起。由此看来自旋锁是使用 CPU 时间换取线程阻塞与调度的开销,但是很有可能这些 CPU 时间白白浪费了。
**喜欢这篇文章的朋友记得点赞、关注哦!
无论是一个初级的 coder,高级的程序员,还是顶级的系统架构师,应该都有深刻的领会到设计模式的重要性。
程序员A:这里我用了XXX设计模式
程序员B:那我大致了解你程序的设计思路了
项目经理:今天客户有这样一个需求…
程序员:明白了,这里我使用了XXX设计模式,所以改起来很快
程序员A:B,你怎么想到要这样去构建你的代码
程序员B:在我学习了XXX设计模式之后,好像自然而然就感觉这样写能避免一些问题
程序员A:B,你这段代码使用的是XXX设计模式对吗?
程序员B:不好意思,我没有学习过设计模式,但是我的经验告诉我是这样写的
从设计思想解读开源框架,一步一步到Spring、Spring5、SpringMVC、MyBatis等源码解读,我都已收集整理全套,篇幅有限,这块只是详细的解说了23种设计模式,整理的文件如下图一览无余!
资料领取方式:点击这里下载
感觉这样写能避免一些问题
程序员A:B,你这段代码使用的是XXX设计模式对吗?
程序员B:不好意思,我没有学习过设计模式,但是我的经验告诉我是这样写的
[外链图片转存中…(img-hgtY2S23-1623738049446)]
从设计思想解读开源框架,一步一步到Spring、Spring5、SpringMVC、MyBatis等源码解读,我都已收集整理全套,篇幅有限,这块只是详细的解说了23种设计模式,整理的文件如下图一览无余!
资料领取方式:点击这里下载
[外链图片转存中…(img-7fzDdikk-1623738049447)]
搜集费时费力,能看到此处的都是真爱!