相信看了这个标题的同学，对这个问题以已经非常不陌生了，信手拈来redisson的几大特性：
【多个业务线同一时刻n条扣款，如果用setnx，我怎么监控的加锁解锁线程？死锁不得发生呐？】
redisson使用hash结构，业务名称作为key,uuid+线程id作为field，加锁次数作为value，这不就解决上述问题了吗
【加锁有两个策略，一是互斥，二是阻塞。互斥比如说定时任务，同一时刻我需要只执行一次就行。阻塞的话-例如多个业务线同一时刻n条扣款，我不能互斥掉吧，那不得被喷死。我得写个while死循环【标准用语就是自旋】一段时间在获取一次，保证系统都能处理这些请求】
加锁过期时间短-加锁逻辑还没执行完就解锁了是不是很尴尬，过长的话-宕机恢复时间又变长
redisson默认30秒给你执行，30秒没执行完就续约30s，宕机的话恢复时间也不会太长。
原理呢就是使用了netty的时间轮实现。简单点说就是环形数组。
直通车：
RedissonLock --> renewExpiration -->TimerTask
Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
@Override
public void run(Timeout timeout) throws Exception {
ExpirationEntry ent = EXPIRATION_RENEWAL_MAP.get(getEntryName());
if (ent == null) {
return;
}
Long threadId = ent.getFirstThreadId();
if (threadId == null) {
return;
}
RFuture<Boolean> future = renewExpirationAsync(threadId);
future.onComplete((res, e) -> {
if (e != null) {
log.error("Can't update lock " + getName() + " expiration", e);
return;
}
if (res) {
// reschedule itself
renewExpiration();
}
});
}
}, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);
// internalLockLeaseTime默认30s，因此这里默认延迟10s后执行
// 其中TimerTask引用的就是netty中的TimerTask
protected void initTimer(MasterSlaveServersConfig config) {
int[] timeouts = new int[]{config.getRetryInterval(), config.getTimeout()};
Arrays.sort(timeouts);
int minTimeout = timeouts[0];
if (minTimeout % 100 != 0) {
minTimeout = (minTimeout % 100) / 2;
} else if (minTimeout == 100) {
minTimeout = 50;
} else {
minTimeout = 100;
}
// 就是分成了1024个格子，每个格子默认100ms
timer = new HashedWheelTimer(new DefaultThreadFactory("redisson-timer"), minTimeout, TimeUnit.MILLISECONDS, 1024, false);
connectionWatcher = new IdleConnectionWatcher(this, config);
subscribeService = new PublishSubscribeService(this, config);
}
大白话讲就是：例如将一个圆分成4等分，1，2，3，4，从1到2需要100ms，那么我需要计算延迟500ms需要走几步，下标是多少？
既然是时间总要跳动嘛，没猜错就是sleep
