目录
- JVM内存模型
1)原子性
2)可见性
3)有序性 - voliate
- 线程
- Java线程
- Synchronized的作用与原理
- ReentrantLock
- ThreadLocal
Java内存模型(Java Memory Model,JMM)
Java内存模型本身只是一种抽象的概念,它声明了一系列规则或规范(主要是声明了主内存与工作内存交互的一些细节),来解决Java在硬件层面上内存访问的差异,也是Java得以跨平台的原因之一。
从内存模型的角度出发,Java中内存可分为主内存和线程工作内存两种,所有变量都存储在主内存中,而线程工作内存主要存储线程私有数据。 主内存是共享内存区域,所有线程都可以访问,但线程并不能直操作主内存中的变量,线程如果想操作主内中的变量,需要先将变量从主内存中拷贝到自己的工作内存中,操作完成后再将变量刷回主内存,只有当数据刷回主内存后,最新的结果对其它线程才是可见的(对于volitile变量同样如此),也就说线程之间的通信(这里指可见性)都必须通过主内存来完成。比如下图
注:这里的主内存与工作内存与堆、栈并不是同一层次上的划分,出发角度不一样,前者是为了解决内存访问差异而划分的,后者代表程序运行时内存的划分。但从变量存储的区域上来看,主内存可对应理解成堆,存储对象但不包括存储局部变量及方法参数,而工作内存则可以对应理解成栈,存储线程局部变量及方法参数等。
Java内存模型的特征
可见性:可见性是指当线程修改共享变量时,其它线程何时可以看到修改后的信息。上面已经说过,只有当数据刷回主内存之后,对其它线程才是可见的。所以这种可见性不一定是及时的,线程A对共享变量的修改会先反映在自己的工作内存中,然后再写回主内存中,如果在修改完但还没有回写的情况下,线程B去获取此时得到的仍然是旧值。针对这种情况,Java提供了volatile关键字,来保证并发修改下变量的可见性,关于volatile稍后说明。
原子性:表示对共享数据某个操作的原子性,由于整个操作的原子性,所以在保证原子性的同时也保证了可见性。java中可以简单的通过synchronized、lock等来达到,synchronized也稍后说明。
有序性:出于优化的考虑,JVM有可能会对指令进行重排序,所以指令的执行顺序并不一定等于代码的编写顺序,但JVM保证最终逻辑上的有序性。比如int a = 3; int b = 4; int c = a + b; 执行时JVM并不保证a一定比b先定义,但从逻辑上会保证,c一定在a,b定义之后才会执行。对于被volatile修饰的变量,jvm不会对其进行重排序。
voliate关键字的作用
对volatile变量的操作同样也遵从内存间的交互规范,与普通变量的区别在于:
- 对volatile变量的修改会保证及时(同时)反映到线程工作内存和主内存中,而且在每次使用volatile变量前线程都会先从主内存中获取最新值。这点就保证了对volatile变量修改的及时可见。
- 除可见性外,对于volatile变量jvm不会进行指令重排,指令的执行顺序和程序中的顺序严格一致,如volatile int a =3; int b = 4;JVM会保证a在b之前定义。再比如在JDK1.5之前双重check的懒汉式单例也需要用到volatile来确保对象可以正常使用,原因是,对象创建一般会经历内存分配—>初始化—>返回对象引用等一系列操作。但由于对象引用在内存分配之后就已经确定了,与对象是否初始化并没有逻辑上的关系,所以如果指令重排的话,对象就有可能在尚未初始化完成就提前返回了,即内存分配—>返回对象引用—>初始化,使用的时候,就有可能出现问题。
- volatile虽然保证对变量修改的及时可见,但并不能保证操作的原子性。
/** 并发情况下,及时获取对该值的修改 */
volatile boolean isStop = false;
public void execute(){
while(isStop){
...
}
}
public void toStop(){
isStop = true;
}
线程简介
线程可以分为内核线程(KLT)和用户线程(UT)两种,内核线程由操作系统分配,程序一般不直接调用,而是通过调用系统为内核线程提供的接口—轻量级进程(LWP),去调用内核线程,轻量级进程与内核线程是一对一的关系,每个轻量级进程都是一个独立的调度单元。Java线程模型就是基于操作系统原生线程模型来实现的,在window和unix下,可以理解为下图:
用户线程建立在用户空间的线程库上,创建、销毁、同步、调度等操作都在用户态中完成,不需要内核参与,因此它的操作相对来更快速而且消耗更低,但难点在于由于没有内核线程的支持,需要手动切换、调度等操作,实现起来非常复杂,目前基于纯用户线程的设计已经很少用了,某些情况下两者会配合使用。
Java线程简介
线程状态:java线程主要有5种状态new、runnable、blocked、wait/timed_waiting(有限wait)、terminated(执行完毕),通过getState()可获取当前状态。
优先级:优先级从1-10(默认5),新线程优先级默认继承于父线程。 这里的优先级只是Java中的划分,并不对应底层系统的优先级。
守护线程:守护线程在后台运行,当程序中全是守护线程时,jvm会自动退出。在守护线程中应该永远不要去访问如文件、数据库资源这些操作,因为守护线程很可能在任何地方被中断。
sleep(millis):让当前线程休眠一段时间,休眠时间是由参数设定,线程状态由runnable转为timed_waiting,休眠期间释放cpu资源但不释放监视器。在时间到达或线程被中断前,该线程都不会再被调起。在waiting期间如果该线程被任何其它线程中断,则该方法抛出异常,并且清除中断标记。
wait()/wait(millis)、notify()/notifyAll():线程状态由runnable转为waiting/timed_waiting,与sleep()的区别在于它等待时间到达或其它线程notify,且在waiting期间释放cpu资源释放锁,同样受线程中断影响。这两组方法位于根类Object中,两者配合实现一种等待—唤醒的线程协作方式,常用于生产—消费者模式下。
join()/join(millis):等待被调用线程中止,当前线程状态由runnable转为waiting/timed_waiting,所以waiting过程中同样受中断影响。如下:f2等待f1执行完成,main线程又等待f2执行完成。
public static void main(String[] args) throws InterruptedException {
Thread f1 = new Thread(()->{
try {
Thread.sleep(10000);
System.out.println(Thread.currentThread().getName());
} catch (InterruptedException e) {}
});
Thread f2 = new Thread(()->{
try {
f1.join();
System.out.println("f1[end], f2[start]");
} catch (InterruptedException e) {}
});
f1.start();
f2.start();
f2.join();
System.out.println("over");
}
yield():使正在运行的线程释放cpu资源重新回到可执行状态,线程状态由runnable(正在执行)到 runnable(可执行),所以线程有可能马上又被执行,由于不会进入wait状态,所以yield()方法并不受线程中断的影响。此外yield()方法只能使同优先级或者高优先级的线程得到运行的机会。
interrupt():中断线程,本身只是设置线程的中断标记而已,但中断会使处于waiting期间的线程抛出一个中断异常InterruptedException,原因是由于线程处于waiting期间,无法被调起执行,不能自己检测中断,所以JVM会通过抛出异常的方式来唤醒线程。通过中断/处理中断异常/检测中断状态也是一种比较常见的线程间通信的协作方式。
终止线程会释放它已经锁定的所有监视器,很容易造成的问题就是数据不一致性。这就相当于一个DB事务中途退出,对于DB而言事务中途退出会导致事务全部回滚,这没什么问题,但在Java程序中,原子性操作的中途退出并没有回滚一说,而是会产生并发问题,所以数据不一致性的问题就很可能产生。即使要终止线程也可以通过上方说的中断方式,来安全退出。
stop():线程挂起
suspend()与恢复
resume():这两个方法在Java中被标记为过时的不再使用的方法,原因是因为通过suspend()挂起的线程,不会释放锁,直到在其它线程中调用resume()恢复,且继续运行完成才会释放锁。因此有可能造成两种情况:一就是如果调用resume()的线程也需要获取相同锁,由于原线程并未释放,那么就会造成死锁。二如果resume()在suspend()之前被执行,则原线程永远也无法被恢复。与wait()/notify()的区别在于情况一,wait会释放锁所以不会造成死锁情况,情况二的话wait也不可避免。
public void testDeadlock() throws InterruptedException{
final Object lock = new Object();
Thread t = new Thread(()->{
synchronized (lock) { //lock
try {
Thread.sleep(1000);
} catch (InterruptedException e) {}
System.out.println("----t.running");
}
});
Thread suspend = new Thread(()->{
t.suspend();
System.out.println("----t.suspend");
});
Thread resume = new Thread(()->{
synchronized (lock) {
t.resume();
System.out.println("----t.resume");
}
});
t.start();
Thread.sleep(100);
suspend.start(); //suspend
Thread.sleep(100);
resume.start(); //resume
t.join();
suspend.join();
resume.join();
System.out.println("----over");
}
线程异常处理:
除了对线程内部的代码进行try...catch外,也可以设置异常处理程序
@Test
public void testUncaughtExceptionHandler() throws InterruptedException{
Thread th = new Thread(()->{
int i = 1/0;
});
th.setUncaughtExceptionHandler(new UncaughtExceptionHandler() {
@Override
public void uncaughtException(Thread t, Throwable e) {
System.out.println("由于没有捕获异常,所以执行自定义的处理方式" + e.getMessage());
}
});
th.start();
}
Synchronized块的作用与原理
synchronized块可以保证操作的原子性和可见性,synchronized底层通过监视器(或内置锁)实现,监视器在jvm中的模型可分为:入口区、持有者、等待区三部分。
synchronized块的进入和退出分别对应指令monitorenter、monitorexit,且synchronized同步块对同一线程是可重入的,重入通过为内置锁关联一个计数器和持有者线程来实现,计数器为0时即表示监视器未被任何占用。当某线程请求获取到一个未被占用的锁时,JVM将记录锁的持有者,并计数+1,如果同一线程再次请求获取这个锁,计数器依次+1;持有线程每退出一个监视块时,计数器-1,当计数器为0时,则会释放锁。即每执行一个monitorenter对应计数+1,monitorexit对应计数-1。
- 当一个新的线程想要获取该监听器,但该监视器已被其它线程占用时,新线程将会进入入口区。
- 持有者代表当前持有监视器的线程,持有者线程可以多次获取监视器而不会被自己阻塞。
- 等待区是指已进入监视区域但中途由于某种原因(比如等待I/O操作、等待队列消费或生产)而放弃持有监视器的线程。
ReentrantLock重入锁
reentrantLock与synchronized很相似,在JDK1.5之前,前者性能更好,1.6起两者性能就差不多了,甚至在往后的JVM会更倾向于synchronized进行改进,所以建议在用synchronized能解决的情况下就使用synchronized。
目前来看,两者主要是表示形式及功能丰富上存在一些差异(reentrantLock以api的方式进行调用,lock()、unlock()通常使用配合 try...finally使用,后者以原生层面上的互斥锁表现),相对原生的synchronized,reentrantLock提供了一些更高级的功能,如获取可中断,设置非/公平锁、条件等(synchronized 是一个非公平性锁)。
如下是JDK中自带的一个经典使用示例(生产者-消费者模式)
- 获取可中断:指在获取锁的过程中,可以响应中断操作。如lockInterruptibly()、 tryLock(long timeout,TimeUnit unit)
- 公平锁:通过new ReentrantLock(true)设置,多线程并发情况下,公平锁倾向于优先将锁分配给等待时间最长的线程。但对于无参的tryLock()公平锁不起作用,只要当前锁可用就被进行分配,而不管其它线程的等待。
- 多个条件
Condition
:Condition配合lock一起使用,来实现多条件的锁与唤醒操作。其实它就相当于Object中的wait/notify,只不过使用wait()/notify()时要求当前线程必须先持有对象锁,而condition的使用则没有这个限制,所以更加灵活。
final Lock lock = new ReentrantLock();
final Condition notFull = lock.newCondition();
final Condition notEmpty = lock.newCondition();
final Object[] items = new Object[100];
int putptr, takeptr, count;
public void put(Object x) throws InterruptedException {
lock.lock();
try {
while (count == items.length)
notFull.await();
items[putptr] = x;
if (++putptr == items.length) putptr = 0;
++count;
notEmpty.signal();
} finally {
lock.unlock();
}
}
public Object take() throws InterruptedException {
lock.lock();
try {
while (count == 0)
notEmpty.await();
Object x = items[takeptr];
if (++takeptr == items.length) takeptr = 0;
--count;
notFull.signal();
return x;
} finally {
lock.unlock();
}
}