JUC面试点汇总

/*corePoolSize核心线程数目*/

用于控制核心线程的个数
    
/*maximumPoolSize最大线程数目*/
    
表示核心线程和救急线程的最大个数，用该值减去corePoolSize核心线程数目就是救急线程个数
    
/*keepAliveTime生存时间*/
    
针对救急线程，当救急线程在该时间段没有接收新任务，就结束该线程
    
/*unit时间单位*/
    
配合keepAliveTime生存时间使用的时间单位
    
/*workQueue阻塞队列*/
    
用于存放处于阻塞状态的任务
    
/*threadFactory线程工厂*/
    
用于生成线程名称
    
/*handler拒绝策略*/
    
当线程均处于运行状态，workQueue满员，且有新任务进入时，handler负责处理新进入的线程
    
- AbortPolicy 让调用者抛出 RejectedExecutionException 异常，这是默认策略
- CallerRunsPolicy 让调用者运行任务 
- DiscardPolicy 放弃本次任务 
- DiscardOldestPolicy 放弃队列中最早的任务，本任务取而代之 
- Dubbo 的实现，在抛出 RejectedExecutionException 异常之前会记录日志，并 dump 线程栈信息，方 便定位问题 
- Netty 的实现，是创建一个新线程来执行任务 
- ActiveMQ 的实现，带超时等待（60s）尝试放入队列，类似我们之前自定义的拒绝策略 
- PinPoint 的实现，它使用了一个拒绝策略链，会逐一尝试策略链中每种拒绝策略

/*线程池构造：我之前有线程池专门的文章，可以深入了解*/

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                          RejectedExecutionHandler handler)

/*共同点*/

wait(),wait(long),sleep(long) 都会导致阻塞，将当前线程暂时放弃CPU使用权
    
/*不同点*/
    
// 方法归属类不同
wait 	属于	Object实体类
sleep 	属于	Thread线程类
    
// 醒来时机不同
wait()：			只有当notify唤醒时才会醒来
wait(long): 	当时间结束，或者notify唤醒就会醒来
sleep(long):	当时间结束才会醒来
    
注意：都可以被打断唤醒！
    
// 锁性质不同
1.wait必须配合锁一同使用，且只有锁对象调用Lock.lock；sleep在任何时间段都可以使用
2.wait在lock时会解除当前锁的限制；sleep若在锁中不会解除当前锁的限制

/*语法层面*/

// 所属类
synchronized：关键字，属于JVM，用C++语言实现
Lock：接口，属于JDK，用Java语言实现
    
// 锁实现
synchronized：在结束同步代码块后自动释放锁
Lock：在结束代码块后，需要手动unlock释放锁
    
/*功能层面*/
    
// 相同点
均属于悲观锁，具备互斥，同步，锁重入功能
    
// 不同点
Lock提供了synchronized所不具备的功能：获得等待状态，公平锁，可打断，可超时，多条件变量
Lock提供了多场景Lock：ReentrantLock，ReentrantReadWriteLock
    
/*性能方面*/

// 性能差距
synchronized：在无竞争情况下，存在轻量级锁，偏向锁，性能较高
Lock：在竞争激烈的情况下，性能更好

/*知识点补充*/

// Lock正常使用

owner：正在运行程序，存有status，表示几重锁，当锁重入时，status++；解除锁时，status--；当status==0，释放锁
blocked queue：阻塞队列
waiting queue：等待队列
    
// 公平锁和非公平锁
    
公平锁：所有任务在进入时均放于阻塞队列按顺序排序并执行
非公平锁：当owner释放锁后，新加入的任务可以和阻塞队列的任务处于同一级竞争锁
    
// 多条件变量
条件变量创建：Condition c1 = Lock.newCondition("c1");
条件变量使用：c1.await();
条件变量唤醒：c1.signal();
条件变量唤醒：c1.signalAll();

必须处于owner才能使用await，唤醒后放于Blocked Queue尾部等待

/*可见性*/

当前线程对数值的修改是否对其他线程可见？
    
问题产生原因：
    CPU和内存之间还有一层缓存区，当使用数据较多时，会直接将内存的数据放入缓存区，然后直接从缓存区调入数据
    这时倘若另一个线程修改了内存中的数据，但是原线程仍旧从自己的缓存区读取数据，就会导致数据不可见
    
/*有序性*/
    
当前线程内的代码是否按照编写顺序执行？
    
问题产生原因：
    JVM存在自动编写机制，当出现同级别的代码时，JVM会自动优化代码顺序，加快速度，可能导致代码执行顺序错乱
    
/*原子性*/
    
当前线程内的代码是否为一次执行？
    
问题产生原因：
    线程是由CPU调度使用的，倘若线程调度到达指定时间片，可能就会导致线程内代码未完成执行而被其他线程使用的情况

/*可见性*/

Volatile可以保证数据的可见性

Volatile会使该属性的每次读取都默认从内存中读取（该属性不会被存放于缓冲区）
    
/*有序性*/
    
Volatile可以保证数据的有序性
    
Volatile存在写屏障和读屏障
    写屏障出现在属性输入之后，在写屏障之前的代码顺序不会变更
    读屏障出现在属性读取之前，在读屏障之后的代码顺序不会变更
    
/*原子性*/
    
Volatile无法保证数据的原子性！

/*悲观锁*/

代表：
    Synchronized
    Lock
    
特点：
    1.核心思想：当前线程占用锁后，才能操作共享数据，只有当当前线程结束操作后，其他线程才能竞争
    2.线程的运行与阻塞都会导致上下文切换，频繁的上下文切换会导致CPU速度降低
    3.悲观锁大部分都存在自旋现象，在获得锁时会多次尝试来减少上下文切换次数
    
/*乐观锁*/
    
代表：
    Atomic系列
    AtomicInteger
    
特点：
	1.核心思想：所有数据都可以操作共享数据，但只有一个线程可以修改数据，其他线程如果修改失败就会不断尝试
    2.由于线程一直运行，不需要阻塞，不涉及上下文切换
    3.由于线程一直运行，需要一个CPU保证其线程的活动，否则单CPU下乐观锁属于负增益，一般线程数不会超过CPU个数

/*乐观锁底层实现*/

// 乐观锁底层其实是采用Unsafe类来完成的

// 1.获得该类的属性对于类的偏移量(第一个参数：类名称.class，第二个参数：类属性名称)
Long BALANCE = unsafe.objectFieldOffset(Account.class,"blance");

// 2.采用unsafe的原子比较赋值方法(第一个参数：类对象，第二个参数：属性偏移量，第三个参数：修改前数值，第四个参数：修改后数值)
// 如果再次检测时，该值和oldInt相同，就将其修改为newInt，否则不作为
unsafe.compareAndSetInt(account,BALANCE,oldInt,newInt);

/*乐观锁代码*/

Thread t1 = new Thread(() -> {
    // 乐观锁需要不断尝试
    while(true){
        // 每次获得当前值
        int oldInt = account.getBalance;
        // 我们假设做++操作
        int newInt = oldInt + 1;
        // 然后启动unsafe的比较赋值(compareAndSetInt会返回一个布尔值表示是否成功)，若成功退出循环
        if(unsafe.compareAndSetInt(account,BALANCE,oldInt,newInt)){
            break;
        }
    }
}).start;

/*悲观锁代码*/

Thread t2 = new Thread(() -> {
    // 悲观锁就是直接采用锁处理即可
    synchronized(Account.class){
        int oldInt = account.getBalance;
        int newInt = oldInt + 1;
        account.setBalance(newInt);
    }
})

/*线程安全？*/

Hashtable和ConcurrentHashMap均属于线程安全类的Map集合
    
/*并发度*/
    
Hashtable：只存在一个锁，所有索引点的操作均在一个锁上，并发度低
    
1.7ConcurrentHashMap：底层由数组+Segment+链表结构，每个Segment对应一把锁，不同Segment不会造成锁冲突
    
1.8ConcurrentHashMap：底层由数组+链表结构，每个链表头对应一把锁，相当于每个索引点对应一把锁，只有同一条链表会产生锁冲突

/*基本问题*/

初始capacity：11
    
扩容：超过0.75
    
索引：hashcode即可，（因为以质数为主，分散性较好，不需要二次hash）

/*基本组成*/

capacity：总共的索引头
    
factor：超过0.75
    
clevel：并发度，也就是Segment的个数
    
每个Segment算是一个大桶，然后大桶中会根据capacity/clevel算出小桶
    
举例：
    capacity：32
    factor：0.75
    clevel：8
    
    这时存在8个Segment，每个Segment中存有四个初始小桶
    
    不同Segment拥有不同锁，不同Segment独自占有并发性
    
    基本形式如下：
    ---- ---- ---- ---- ---- ---- ---- ----
    
/*put操作*/
    
1.hashCode
    
2.hash
    
3.根据hash值二进制的前（clevel二进制为2的n次方）n位的数值来判断放在哪个大桶
    
4.根据hash值二进制的后（小桶大小二进制为2的n次方）n为的数值来判断放哪个大桶
    
举例：
    capacity：32
    factor：0.75
    clevel：8
    
    首先clevel的为2的3次方，小桶大小为2的2次方
    
    假设我们的hash值二进制为 110 1101 0110

    这时我们的大桶取前三位：110 -> 6 -> Segment[6]
    
    这时我们的小桶取后两位： 10 -> 2 -> Segment[6][2]
    
    也就是第七个桶的第三个位置
    
/*扩容*/
    
扩容仅针对每个Segment单独扩容，最开始的桶大小为capacity/clevel，当超过factor，就会自动扩大一倍，单独计算
    
Segment[0]的扩容不会影响到其他Segment的桶大小

/*Segment[0]*/
    
Segment[0]会自动初始化小桶，其他Segment只有在put第一个数时初始化
    
因为Segment[0]类似于一个初始模板，其他Segment会根据Segment[0]的大小来构造，节省空间（懒汉式构建）

/*基本知识点*/

1.8版本的ConcurrentHashMap只包含 数组 + 链表 结构
    
属于懒汉式初始化，我们new一个ConcurrentHashMap并不会产生数组，只有开始put时才会初始化
    
capacity：16
	注意：这里的capacity并不是初始桶大小，而是我们需要插入的数的数量，系统会根据我们书写的capacity更换桶大小
    例如我们写15，系统会为我们分配一个大小为32的桶
    
factor：达到0.75

/*并发依据*/
    
1.8ConcurrentHashMap根据链表头分配不同的锁，也就是如果不是在同一索引下，均可以正常运行
    
/*扩容操作*/
    
扩容是ConcurrentHashMap的考点之一
    
ConcurrenthashMap扩容是从后往前移动数据，每次移动完成该索引点数据，就为其标记为ForwardingNode用来表示已移动
    
ConcurrentHashMap扩容不再是将原数据next更换，而是直接在新数组上创建新数据，将数据拷贝过去，防止并发操作时出现问题
    
/*扩容细节*/
    
当一个线程t1正在进行扩容，另一个线程t2参与该HashMap各项操作：
    
1.get操作：
	I.如果查询的该索引属于ForwardingNode，就去新的数组中查找
    II.如果查询的索引不属于ForwardingNode，就直接查找
    
2.put操作：
    I.如果该索引不属于ForwardingNode，就直接插入即可
    II.如果该索引正在迁移，堵塞
    III.如果该索引已经属于ForwardingNode，帮助线程t1完成扩容后，再进行修改

/*线程安全性*/

ThreadLocal可以实现资源对象的线程隔离，让每个线程各用各的资源对象，避免争用引发的线程安全问题
    
ThreadLocal同时实现了线程内资源共享
    
/*ThreadLocal使用*/
    
每个线程中有一个ThreadLocalMap类型的成员变量，用于存储资源对象
    
1.创建一个ThreadLocal（该ThreadLocal实际上就是ThreadLocalMap的key）
    ThreadLocal<class?> t1 = new ThreadLocal<>();

2.可以调用set方法存储数据（ThreadLocal就是key，资源对象作为value，放入当前线程的ThreadLocalMap集合中）
	t1.set(new String("123"));

3.可以调用get方法查找数据（根据ThreadLocal为key，查找相关数据）
    t1.get();

4.可以调用remove方法删除该数据（根据ThreadLocal为key，删除相关数据）
    
注意点：
    I.当使用set时才会构造map对象
    II.不同的ThreadLocal使用不同的数据结构
    III.扩容时阈值为0.75，每次扩容一倍；存储时采用开放寻址法
    
/*key*/
    
这里的key采用的是弱引用：
    1.Thread可能需要长时间运行（如线程池的线程），如果key不再被使用，可以被JVM的GC所释放
    2.GC仅使key释放，但是value不会释放：
    	I.获得key时，会删除value
  		II.setkey时，会将附近的value删除
    	III.手动remove删除