面经Java开发

联奕一面：

1、这段代码的输出结果是多少？t q z

package com.smart.community.test;public class Test {public class B{static {System.out.println("t");}public B(){System.out.println("z");}}public class A extends B{static {System.out.println("q");}public A(){System.out.println("w");}}public static void main(String[] args) {B a = new A();}  }

2、Kafka、ActiveMQ、RocketMQ和RabbitMQ的区别

3、RocketMQ的推拉模式

推模式：每次producer每次生产了消息，会主动推给broker

推模式：broker将消息推向Consumer 优缺点：延迟小，实时性比较好，简化了Consumer端的逻辑，缺点：推送的速率和消费的速率不好去匹配

拉模式（RocketMQ选择的）：消费者可以根据自身的情况来拉取消息的请求，如果消费者真的出现那种忙不过来的情况下，可以根据一定的策略去暂停拉取，更适合批量消息的发送，缺点是实时性较差

4、RocketMQ是如何实现拉模式

拉取模式分为普通轮询和长轮询两种方式

普通轮训：定时发起请求，服务端收到请求之后无论是否有数据更新，都立即回复

长轮训：Consumer向服务端发起请求，而服务端收到后不会立即去响应，而是hold住客户端连接，等待数据产生变更之后才会回复客户端，或者超过指定时间还未产生变更

对普通轮询进行一定程度的限制，客户端可以随时请求服务端，但是我并不一定立即回复你

5、RocketMQ消息堆积了怎么解决

8、业务执行时间可能超过设置的超时时间问题

（3）业务执行时间可能超过设置的超时时间

1）定时自动去续约（expire key second）

为该锁设置一个较小的lock_timeout，同时每隔一段时间在该锁过期之前，就自动的向服务器延长该锁的lifetime（看门狗）

动态续期：为分布式锁设置一个初始的过期时间，同时启动一个守护线程或定时任务来监控锁的剩余有效期。当检测到锁即将过期而业务操作尚未完成时，自动对锁进行续期，即延长锁的过期时间

使用Redlock算法：如果使用了分布式锁，可以考虑使用Redlock算法来提高锁的安全性和可靠性

合理评估超时时间：通过压力测试来评估业务操作的平均执行时间，然后根据测试结果来合理设置锁的超时时间。可以将超时时间设置为平均执行时间的1到2倍，以降低锁过期导致的问题风险

2）记录业务处理时长，设置过期时间：业务时长+一定时间

每次获取锁后，记录业务代码执行的时长，在redis中存一个上次时长，再次获取锁时设置过期时间为上次时长+N秒

可以创建一个守护线程，也成为看门狗线程，这个线程的任务是实时监控业务线程的执行情况。如果发现业务线程仍在执行中，且未达到预定的超时时间，守护线程就会将锁的过期时间延长
可以使用Redisson工具类，Redisson会启动一个守护线程，这个线程会定期检査锁的状态，并在必要时对锁进行续期

我们可以先给锁设置一个LockTime，然后启动一个守护线程，让守护线程在一段时间后，重新去设置这个锁的LockTime。

看门狗

Redisson的看门狗机制就是这种机制实现自动续期的

Redisson看门狗机制，只要客户端加锁成功，就会启动一个 Watch Dog。

leaseTime 必须是 -1 才会开启 Watch Dog 机制，如果需要开启 Watch Dog 机制就必须使用默认的加锁时间为 30s。
如果你自己自定义时间，超过这个时间，锁就会自定释放，并不会自动续期
续期原理

续期原理其实就是用lua脚本，将锁的时间重置为30s
Watch Dog 机制其实就是一个后台定时任务线程，获取锁成功之后，会将持有锁的线程放入到一个 RedissonLock.EXPIRATION_RENEWAL_MAP里面，然后每隔 10 秒检查一下（internalLockLeaseTime / 3）检查一下，
如果客户端还持有锁 key（判断客户端是否还持有 key，其实就是遍历 EXPIRATION_RENEWAL_MAP 里面线程 id 然后根据线程 id 去 Redis 中查，如果存在就会延长 key 的时间），那么就会不断的延长锁 key 的生存时间。

如果服务宕机了，Watch Dog 机制线程也就没有了，此时就不会延长 key 的过期时间，到了 30s 之后就会自动过期了，其他线程就可以获取到锁