线程状态:
- NEW-新建:创建了线程对象,还未开始执行。
- RUNNABLE-运行:线程对象已在java虚拟机运行,分为就绪(Ready)和运行中(Running)。
- BLOCKED-阻塞:等待获取锁的状态。
- WAITING-等待:在等待另一个线程的动作。 比如,线程调用了wait()后,等待另一个线程的notify()。
- TIME_WAITING-限时等待:同上,只不过有时间限制。
- TERMINATED-完成:线程已执行完成。
Thread、Runnable、Callable:
- Runnable接口只是定义了一个run()方法,当线程执行start()时,会调用该方法。 所以,Thread类其实也是实现了Runnable。
- Runnable需要传入Thread中使用,thread的run方法也是调用runnable的run方法。所以,将同一个runnable对象传入不同的thread,可以共享runnable中的资源;
- Callable:同Runnable相似,要传到thread中执行,但是可以拿到返回值。
Thread常用api:
- 获取和设置对象本身的信息:
getId() :返回 Thread对象的标识符。 getName()/setName():获取或设置Thread对象的名称。 isDaemon()/setDaemon():获取或建立Thread 对象的守护条件。 getPriority()/setPriority():获取或设置Thread对象的优先级。getState():该方法返回Thread对象的状态。
- sleep(): 主动挂起ms时间,不会让出cpu;
- wait是Object方法,obj.wait(),则当前线程会假如obj对象的等待队列中,直到被唤醒。 所以多个线程在操作obj对象时,必须获取obj的锁,wait和notify要处于同步块中。
- yeild(): 当然线程让出cpu资源给其他线程执行(不一定谦让成功)。
- interrupt():中断目标线程,其实只是把线程的一个变量设置为true,并不能真正中断线程。 至于要不要被中断,要看目标线程本身的逻辑,比如:
- 目标线程中可以调用interrupted方法判断,如果有了中断标记,就执行return退出。
- 假如有了中断标记,目标线程在调用阻塞方法如wait、join、sleep等方法时,会抛出InterruptedException异常,需要正确处理这些异常(比如catch异常并退出)。
- interrupted():判断目标线程是否被中断,但是将清除线程的中断标记。
- isinterrupted():判断目标线程是否被中断,不会清除中断标记。
join() :暂停线程的执行。比如调用t1.join(),则暂停当前线程,直到t1线程执行完成。
如过调用多个线程的join方法,多个线程互不影响,并行执行,只是当前线程要先等多个线程都执行完。 currentThread(): Thread 类的静态方法,返回执行当前代码的 Thread 对象。
对象锁以下两种:
public void method1() { synchronized (this) { } } public void synchronized method1(){ }
类锁:
public static void method2() { synchronized (MyClass.class) { } } public static void synchronized method2() { }
锁的本质,就是保证共享资源,在同一时间只能有一个线程可以访问。
锁的原理,就是在对象的内部有个标志(state:0-没有被占用;1-被某个线程占用),如果被占用就记录该线程的id。 此外,对象还维护了一个list,记录所有等待锁的线程id,锁释放后,就从list中取一个线程唤醒。
一个内存队列,多个生产者在存放数据,多个消费者在读取数据。要实现这样的模型,就要做到几件事:
- 内存队列本身要加锁,才能实现线程安全。
- 阻塞。当内存队列满了,生产者放不进去时,会被阻塞;当内存队列是空的时候,消费者无事可做,会被阻塞。
- 双向通知。消费者被阻塞之后,生产者放入新数据,要notify()消费者;反之,生产者被阻塞之后,消费者消费了数据,要notify()生产者。
当然了,第二和第三,可以用其他方法,比如自己沉睡一段时间后重试,但是这样效率低且不实时。所以可以用 wait 和 notify,实现阻塞和通知。
问题:
1、为什么wait() 和 notify() 是Object的函数,而不是作为Thread自己的函数?
因为多个线程针对的是资源本身,也就是锁的对象。上面也说了,synchronized锁的对象内,记录了获取锁的线程id 和 所有等待的线程列表。所以,只能由资源对象去决定,应该阻塞 和 唤醒 哪个线程。
2、为什么wait 和 notify 必须和synchronized一起使用?
两个线程之间要通信,对于同一个对象来说,一个线程调用该对象的wait(),另一个线程调用该对象的notify(),该对象本身就需要同步!
3、为什么wait的时候必须释放锁?
因为wait的时候会进入阻塞状态,这时候还在synchronized中,其他线程也无法获取对象锁 调用notify,就会发生死锁。
4、notify 和 notifyall的区别?
notify是唤醒一个; notifyall是唤醒所有; 尽量使用notifyall,因为notify唤醒的那一个,可能无法正常使用了,就没有办法获取锁继续往下走,然后唤醒其他的,导致死锁。
5、为什么wait方法要在while循环内? 使用if可以吗?
当线程调用wait进入等待,然后在下一次被唤醒并获取到锁后,还要执行后续代码。 那么,在执行后续代码前,还需要再次判断,是否要重新wait。 如果使用if,被唤醒后一定会执行后续代码,可能会出问题。
4、线程关闭
不要stop和destory,原因很简单,如果强制杀死线程,则线程中所使用的资源,例如文件描述符、网络连接等无法正常关闭。
因此,一个线程一旦运行起来,不要强行关闭,合理的做法是让其运行完(方法执行完成),干净地释放掉所有资源,然后退出。如果是一个不断循环运行的线程,就需要用到线程间的通信机制,让主线程通知其退出。
5、守护线程
线程分为守护线程和用户线程,调用某个线程的setDaemon(true)方法,就会将其设置为守护线程。
当所有的用户线程退出后,整个JVM进程就会退出,而不会在乎守护线程的状态。 而守护线程会在主线程退出后,自动退出。 因此,守护线程一般可以用来监控用户线程来做事,
比如一些后台任务,定时任务,监听器,垃圾回收器等,就是用的守护线程。
1、并发与并行:
并发:在一个处理器上快速切换多个任务,看起来像是同时运行。
并行:在不同的处理器、计算机上同时运行多个任务。
2、同步:
简单说就是同一时间内,只能有一个执行。
3、不可变对象:
初始化后,不能修改其可是状态(比如它的属性值)。 就像Strign类,如果给它赋新的值,其实会创建另一个新对象。
因此,不可变对象是线程安全的。
1、数据竞争:多个线程对一个非同步的数据,同时操作,可能造成不同的结果
2、死锁: 两个或两个以上的线程在执行过程中,由于竞争资源或者由于彼此通信而造成的一种阻塞的现象,若无外力作用,会永远的阻塞下去。
3、活锁:任务或者执行者没有被阻塞,但是由于某些条件没有满足,导致一直重复尝试—失败—尝试—失败的过程。
4、资源不足:多个线程等待某一资源的释放,然后选择下一个线程执行该资源。 但是可能由于系统没有涉及良好的算法等因素,导致资源不足,这些线程长时间等待下去。 所以,在等待时需要加入时间考虑。
5、优先权反转:并发时,可能低优先权的任务先获取到资源,就会在高优先权的任务前执行。
jmm为java内存模型,讲之前,先看看 CPU缓存模型:
CPU缓存模型:
CPU Cache:
我们知道,CPU是负责执行指令的;自身的频率和指令执行的速度非常快,比内存还要快好几个级别。 如果,每次读写都要和内存交互,性能就会很低。 因此,CPU也有自己的缓存,用于解决 CPU处理速度 与 内存读写速度不匹配的矛盾;就像内存缓存的是硬盘数据,用于解决硬盘访问速度过慢的问题。
如图,现在的电脑都有多个CPU,每个CPU都有多个核。 每个核里面,都有自己的缓存L1,L2。 多个核共享L3, 多个CPU共享主内存。 L1,L2,L3就是CPU自己的缓存(整体可以都看做CPU Cache),他们的工作方式是,将内存的数据复制到CPU Cache中使用,计算完成后将结果写入内存中。
但是,如果多个线程同时从主内存当中,读取了一个副本,都进行各自的计算,就可能造成结果不一致的问题。 因此,它们需要遵循一定的规范协议来保证数据同步,即 缓存一致性协议。 这些规范就是操作系统通过内存模型定义的,无论windows、linux,他们都有自己的内存模型。
寄存器:
寄存器是CPU内部的最快和最小的存储器,比CPU Cache更快,直接和CPU核心交互。 它有很多buffer组成,如store buffer,load buffer等。 它和CPU Cache 都是存储器,但CPU Cache并不是由寄存器组成的。
内存可见性问题:
有了缓存一致性协议的保障,对于CPU Cache(L1, L2, L3)和主内存,数据是同步的。 但是呢,在寄存器和这些缓存之间,是异步的。 比如向内存中写一个变量,会先保存在store buffer里面, 稍后异步的写入L1中,同时同步的写入主内存中,最终可能造成数据不一致。 因此,从宏观层面来看,可以看做: 每个cpu都有自己的缓存,缓存和主内存不同步,造成结果不正确。
对应到java中,就是JVM抽象的内存模型了: JMM(Java Memory Model)
指令重排序 与 内存可见性问题 的关系:
程序执行时,为了提升效率,编译器和处理器都会对代码的指令重新排序,不一定按照你写的代码顺序执行。 一般分为: 编译器对于指令的重排、指令并行重排、内存系统对指令的重排。 这些重排序,在单线程下结果不会有变化,但是在多线程下,可能会出问题。 比如上面说的,store buffer延迟写入的内存可见性问题,就是重排序的第三种。 因此,我们需要 内存屏障 来保证。
内存屏障:
一种计算机硬件或软件机制,用于控制处理器和内存之间的数据同步和可见性。 它可以禁止编译器重排序和 CPU 重排序。
编译器的内存屏障,只是为了告诉编译器不要对指令进行重排序。当编译完成之后,这种内存屏障 就消失了,CPU并不会感知到编译器中内存屏障的存在。
CPU的内存屏障,是CPU提供的指令,可以由开发者显示调用。
内存屏障通常包含以下几种:
- LoadLoad:禁止读和读的重排序,保证两次读按顺序执行。
- StoreStore:禁止写和写的重排序,保证两次写按顺序执行。
- LoadStore:禁止读和写的重排序,保证先读后写。
- StoreLoad:禁止写和读的重排序,保证先写后读。
Java在Unsafe类中提供了三个:
- loadFence=LoadLoad+LoadStore
- storeFence=StoreStore+LoadStore
- fullFence=loadFence+storeFence+StoreLoad
JMM:
JMM模型,在上面简单看过,它抽象了线程和主内存的关系,也就是每个线程有自己的缓存副本,这些线程共享主内存。为了保证这种模型下不出问题,JMM描述了一组规范,定义了程序中对各个变量的访问方式。
比如:使用volatile修饰的变量
- 写操作前,插入StoreStore,保证多次写按顺序操作;
- 写操作后,插入StoreLoad,保证写完后再读;
- 读操作前,插入loadFence,保证读写顺序;
总之,volatile修饰的变量,可以让多个线程之间拿到内存最新的值,保证读写不乱序。final也可以保证数据不被更改,还可以使用像synchronized、Lock等同步机制,也可以保证多个线程之间按串行。 他们都可以禁止重排序,保证最终结果。作为开发人员,不需要关注底层实现,正确使用即可。