近期java面试总结-java(持续更新)

目录

1.线程池几种参数的作用，特别注意核心线程数、最大线程数

2.局部异常和全局异常的先后关系 

3.锁synchronized 和 ReentrantLock 

3.1说说你了解的synchronized

3.2 ReentrantLock 怎么实现公平锁

1.线程池几种参数的作用，特别注意核心线程数、最大线程数

7个参数：核心线程数、最大线程数、空闲线程空闲时间、时间单位、队列、线程工厂、

拒绝策略 

例子：任务数n=8时，2个核心线程去处理其中的2个任务，其余6个中3个放入阻塞队列queue中，还剩余3个直接被线程池中非核心线程（线程池中最大线程数为6）直接执行。

核心线程数：一直存在，不会销毁。任务数大于核心线程数小于最大线程数会创建非核心线程梳理。达到最大线程后放入队列

最大线程数：线程池允许的最大线程数

 你当前项目中 核心线程数 、最大线程数、队列怎么设置的

/** 线程池核心线程数，即线程池中常驻的线程数量 **/
private static final int DEFAULT_CORE_POLL_SIZE = 10;

/** 线程池允许的最大线程数，非核心线程在超时之后会被清除，受限于 CAPACITY，需要根据实际的物理机配置去计算 **/
private static final int DEFAULT_MAXIMUM_POOL_SIZE = 1024;

/** 线程没有任务执行时可以保持的时间【非核心线程】 **/
private static final long DEFAULT_KEEP_ALIVE_TIME = 0;

/** keepAliveTime 的时间单位 **/
private static final TimeUnit DEFAULT_TIME_UNIT = TimeUnit.MICROSECONDS;

/** 阻塞队列的最大容量 **/
private static final Integer MAX_WORK_QUEUE_CAPACITY = 1024*10;

2.局部异常和全局异常的先后关系 

局部异常的优先级高于全局异常，会先执行局部异常，再执行全局异常

3.锁synchronized 和 ReentrantLock 

3.1说说你了解的synchronized

synchronized是一个关键字

synchronized作用于jvm层面，锁住的是对象头。

几种状态根据线程的竞争情况转换：无锁、偏向锁、轻量级锁、重量级锁

根据代码锁的位置，决定锁的颗粒度

3.2 ReentrantLock 怎么实现公平锁

lock锁由 一个变量state+aqs队列实现

公平锁：

lock()->acquire()->tryAcquire()

先去判断锁的状态，如果是0，则cas 抢到锁就把状态改为1，没抢到就添加到队列尾部

非公平锁：

lock()->acquire()->tryAcquire()

lock()不管队列里面是否有数据，先直接cas，然后在执行公平锁操作

4.消息队列积压了怎么办

解决思路：

　　1. 如果仅仅是 Consumer消费速度落后于消息生产的速度的话，可以考虑采用扩容消费者群组的方式。

　　2. 如果积压比较严重，积压了上百万、上千万的消息。

　　　　a. 修复现有 Consumer问题，并将其停掉。

　　　　b. 重新创建一个容量更太的 topic，例如 patition是原来的 10倍，临时建立好原来10倍的 queue数量。

　　　　c. 重新写一个临时 Consumer 程序，消费原来积压的队列。该 Consumer不做任何耗时的操作，将消息均匀写入新创建的队列里。

　　　　d. 征用 10 倍的机器来部署 已经修复好的 consumer 程序，每一批 consumer 消费一个临时 queue的数据。这种做法相当于临时将 queue资源和 consumer资源扩大 10 倍，以正常的 10 倍速度来消费数据。

　　　　e. 消息积压解决后，恢复原有架构。

　　3. 如果消息已经丢失

　　　　由于有的消息队列有过期失效机制，造成了大量的消息丢失。这种情况下只能将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入 MQ 里面去。

　　4. 消息队列快写满了

　　　　如果消息积压在 MQ 里，很长时间都没有处理掉，此时导致 MQ快些满了，这个是时候还有别的办法吗？没有，谁让第二个方案执行的太慢了，临时写程序，接入数据来消费，消费一个丢弃一个，都不要了。快速消费掉所有的消息，然后走第三个方案，补数据。