java map 内存可见性_面试题-Java多线程基础、实现工具和可见性保证(新更新版)...

前言

Java多线程部分的题目,是我根据Java Guide的面试突击版本V3.0再整理出来的,其中,我选择了一些比较重要的问题,并重新做出相应回答,并添加了一些比较重要的问题,希望对大家起到一定的帮助。

系列文章:

Java多线程

多线程基础

何为线程,何为进程?

进程是程序的一次执行过程

线程是比进程更小的执行单位,一个进程中可以创建多个线程

说说并发与并⾏的区别?

并发:同一时间段内,多个程序都在执行

并行:单位时间段内,多个程序同时执行

为什么要使⽤多线程呢?

单核时代,多线程主要是为了提高cpu和IO设备的综合利用率;

多核时代,主要是为了提高CPU的利用率。

编写多线程程序可能会存在的一些问题(重要)

安全性问题:由于编译器、硬件和运行时的机制是不可预测的,假如没有正确的同步机制,可能会产生安全性问题。

原子性:一组操作未必如我们所想的是原子的,中间可能被其他线程干扰。

可见性:线程对共享变量的修改,未必对其他线程是可见的。

活跃性问题:某个操作无法继续执行下去时,就会出现活跃性问题。比如:死锁饥饿活锁等等

性能问题:上下文切换开销;同步机制带来的其他开销等等

线程生命周期中有哪些状态?(核查线程问题时,了解每种状态代表的含义是基础)

NEW:一个线程被创建出来时,start()被调用之前,状态为NEW

Runnable:调用start后,线程状态变为Runnable

Running:上CPU执行中,外部不可见

Ready状态:排队等待执行,外部不可见

IO wait:等待IO操作,外部不可见

Blocked:线程等待获取锁

Waiting:

TIMED_WAITING:有超时时间的等待

WAITING:没有超时时间的等地啊

Terminated:执行完毕,进入Terminated状态

java map 内存可见性_面试题-Java多线程基础、实现工具和可见性保证(新更新版)..._第1张图片

线程的中断机制:如何正确的干涉线程的执行过程

首先要明确,中断并不是停止,中断可以理解为一种通知机制。

线程在不同的状态时,对中断的响应也不同。

Runnable状态:线程处于Runnable状态时,调用interrupt方法只会设置线程的中断标记位为true,需要线程在执行代码中自己判断中断标记位来得到通知。

注:判断中断标记位的方法有两种:

isInterrupted:实例方法

interrupted:静态方法,会清空标记位

Blocked状态:线程处于Blocked状态时,调用interrupt方法只会设置线程的中断标记位,线程什么都不会做,会继续Blocked。

Timed_wating或Waiting:线程处于Waiting相关状态时,调用interrupt方法会设置线程的中断标记位,并且线程内部会自动监测这个中断状态,当监测到为true,会抛出InterruptedException,清空标记位,线程会重新变为Runnable状态

总结:中断线程对Blocked方法无效,不会立即响应,线程会一直阻塞。已经在运行中的线程需要自己监测中断标记位;在Waiting状态中的线程可以自动监测标记位,通过抛出异常中断。

特殊情况:

当线程处于等待IO(IO wait状态)时,调用interrupt方法会设置标记位

如果Channel是可中断的,会抛出ClosedByInterruptException异常

如果是不可中断的,比如selector选择器,会从阻塞中立即返回

什么是上下⽂切换?

当前任务执行完CPU的时间片切换到下一个任务时,会提前保存自己的运行状态,以便下次切换回这个任务时,可以再加载这个状态及时恢复现场。

上下文切换通常是计算密集型的,如果线程数远大于cpu数量,cpu会耗费大量的时间在上下文切换这个操作上,影响实际执行用户代码的时间比例。

什么是线程死锁?如何避免死锁?

问题一:线程A持有资源2,线程B持有资源1,他们同时都在等待对方的资源,而一直阻塞下去。

问题二:产生死锁需要同时具备下面四个条件,我们只需要破坏任意的其中一个,就可以防止死锁。

互斥:资源任一时刻只能由一个线程占有;破坏方案:无法破坏

请求和保持:一个线程获取不到资源阻塞时,对已经获取的资源保持不放;破坏方案:线程一次性申请全部需要的资源

不剥夺:其他线程不能剥夺已经被占有的资源;破坏方案:当线程申请另外的资源阻塞时,对已经申请到的资源及时释放。

循环等待:线程形成了首尾相接的循环等待条件;破坏方案:按顺序申请资源

说说 sleep() ⽅法和 wait() ⽅法区别和共同点?

共同点:两个方法都可以暂停线程的执行

不同点:

sleep不释放锁,等到超时时间自动苏醒

wait会释放锁,如果不带超时时间,需要其他线程调用notify相关方法唤醒;如果带超时时间自动苏醒

为什么我们调⽤ start() ⽅法时会执⾏ run() ⽅法,为什么我们不能直接调⽤run() ⽅法?

new一个线程之后,线程进入了NEW状态,调用start方法后会做一些准备工作然后准备上CPU执行时间片,如果直接调用run方法,和普通方法的执行就一样了,是调用者线程去执行run方法中的逻辑。

Java中的保证线程安全性的相关工具

为了解决多线程编程中的线程安全性问题,Java提供了多种工具供我们选择。

synchronized

可以解决什么问题?

synchronized可以保证原子性和可见性。

如何使用

synchronized可以使用在实例方法,静态方法和代码块中。

实例方法锁定的是this

静态方法锁定的是当前的Class对象。

代码块中可以自定义一个对象。

JVM对synchronized的性能优化

偏向锁

机制:如果一直是同一个线程反复申请锁,那么可以直接进入代码块,不需要做其他同步操作。

适用场景:某一个线程会反复进入同步代码块,就省略了加锁操作。

轻量级锁

机制:当申请偏向锁失败时(有其他线程在占用),会升级,申请轻量级锁

适用场景:多个线程交替执行同步代码块内容,并且有较短时间的重叠(如果没有重叠,就会一直保持偏向锁,如果重叠较长,就会导致锁升级)

重量级锁

机制:申请轻量级锁失败,会升级为重量级锁,首先会先自旋若干个空循环,如果循环之后还是无法获取锁,只能等待操作系统挂起

适用场景:多个线程同时执行同步代码块,并且每个线程占用锁时间短(自旋一阵大部分可以成功申请到锁)。

锁消除

机制:JIT会通过逃逸分析自动去除不可能出现竞争的锁

一些问题整理

讲⼀下 synchronized 关键字的底层原理?

如果是同步代码块,会使用两个JVM指令,monitorenter和monitorexit

如果是修饰方法,没有使用上面这两个指令,而是使用了ACC_Synchronized标识,JVM通过这个标识可以在执行方法前进行相关的同步操作。

Reentrant Lock

可以解决什么问题?

和synchronized一样,Reentrant Lock也可以保证原子性和可见性。

Reentrant Lock 和synchronized的区别

首先要明确,synchronized是在JVM层面实现的,而Reentrant Lock是在Java代码层面实现的。

Reentrant Lock的性能在jdk1.5之前是要远远优于synchronized,但是Jdk1.6版本虚拟机对synchronized做了优化(就是上面讲过的偏向锁等等),使得他们的性能几乎差不多了。

既然如此,为什么还需要使用Reentrant Lock呢?因为Reentrant Lock和synchronized相比,提供了更丰富的功能。

可中断锁等待

在前面多线程基础部分,提到过中断。当线程处于BLOCKED状态时(仅指使用synchronized关键字),interrupt函数只能设置中断标记位为true,但是线程依旧保持在阻塞状态。如果使用Reentrant Lock,在interrupt调用后,可以抛出InterruptedException响应通知,并且线程从阻塞状态中返回。

锁申请支持设置超时时间

可以使用tryLock或者待超时参数的tryLock,成功会返回true,失败返回false。不会像synchronized,如果一直申请不到锁,就会持续阻塞。

公平锁

synchronized的实现是非公平的,当锁可用时,会从等待队列中随机选择一个线程。而Reentrant Lock可以设置公平模式,保证不会出现饥饿现象。

可等待不同条件

synchronized的wait方法的实现机制是,把该线程放入锁对象的等待队列中,这个队列只有一个。如果需要区分等待的条件,就无法实现了。Reentrant Lock可以配合Condition使用,区分不同的等待条件,在需要等待的条件上wait就可以。

Volatile

可以解决什么问题?

Volatile只能保证可见性。

可见性保证的实现原理-JMM内存模型

上面提到了锁和volatile工具都可以保证可见性,那么可见性究竟是如何实现的呢?

主内存和线程的本地内存以及通信过程

JMM定义,线程之间的共享变量存储在主内存中,每个线程在自己的本地内存中持有一个共享变量的副本。主内存不仅仅是普通意义上的内存,而是一个抽象的概念,主要包括了编译器缓存、寄存器等硬件相关的优化。当两个线程想要通信,线程A需要把自己本地内存中的共享变量刷新到主内存中,线程B从主内存中获取共享变量的值。示意图如下:

java map 内存可见性_面试题-Java多线程基础、实现工具和可见性保证(新更新版)..._第2张图片

总结:JMM通过控制主内存与每个线程的本地内存之间的交互,来为java程序员提供内存可见性保证。

JMM具体是如何控制主内存和本地内存的交互呢?

我们知道,无法保证可见性的根源源于重排序,在现代PC中,存在着两种重排序。

编译器重排序

处理器重排序

那么要保证可靠性,禁止重排序就可以了。

对于编译器重排序,JMM的编译器重排序规则会直接禁止编译器重排序。对于处理器重排序,JMM会在某些指令处,插入内存屏障来禁止处理器重排序。

Happens-before-更友好的方式来描述操作之间的内存可见性

假如没有Happens-before原则,那么作为程序员的我们,需要去详细了解JMM的编译器重排序规则和内存屏障相关的细节,Happens-before原则,给程序员提供了一个更加友好易懂的视图,方便理解。

具体来说,如果A存在对于B的Happens-before关系,那么A操作一定对B操作可见。下面是几个比较重要的明细原则:

程序顺序规则:一个线程中的每个操作,happens- before 于该线程中的任意后续操作。

监视器锁规则:对一个监视器锁的解锁,happens- before 于随后对这个监视器锁的加锁。

volatile变量规则:对一个volatile域的写,happens- before 于任意后续对这个volatile域的读。

传递性:如果A happens- before B,且B happens- before C,那么A happens- before C。

ThreadLocal

ThreadLocal主要解决什么问题?

ThreadLocal可以实现每个线程都有自己的专属本地变量,实现线程的私有数据,从而保证了线程安全性。

ThreadLocal的原理?

每一个Thread中都有一个threadLocals引用,这个引用指向的是一个ThreadLocalMap类,这个map简单理解就是一个定制化的HashMap。创建一个threadLocal并调用set方法时,实际会获取当前线程的ThreadLocalMap,然后把这个threadLocal作为key存储到map中。

简单来说,每个线程都有一个Map,这个map里面存储的是以 ThreadLocal为key,当前ThreadLocal的泛型类型为数据类型的value值。真实使用的时候,我们会有很多的ThreadLocal分别存储不同类型的值。

这里会有一个内存泄漏的问题,因为作为key的threadLocal是弱引用,每次垃圾回收都会回收他们,所以会产生很多key为null的value,jdk实现中,在getset等方法中会强制扫描为null的key,并清除他们。

项目中如何使用的?

web项目中,会使用ThreadLocal保存当前线程登陆后用户的相关信息,方便后续获取用户的id等信息。

你可能感兴趣的:(java,map,内存可见性)