Netty时间轮HashedWheelTimer原理分析

HashedWheelTimer初始化

public HashedWheelTimer(
    ThreadFactory threadFactory,
    long tickDuration, TimeUnit unit, int ticksPerWheel, boolean leakDetection,
    long maxPendingTimeouts) {
 
    checkNotNull(threadFactory, "threadFactory");
    checkNotNull(unit, "unit");
    checkPositive(tickDuration, "tickDuration");
    checkPositive(ticksPerWheel, "ticksPerWheel");
 
    // 将ticksPerWheel规格化为2的幂，并初始化时间轮
    wheel = createWheel(ticksPerWheel);
    mask = wheel.length - 1;
 
    // 把时钟拨动频率转成以纳秒为单位
    long duration = unit.toNanos(tickDuration);
 
    // Prevent overflow.
    if (duration >= Long.MAX_VALUE / wheel.length) {
        throw new IllegalArgumentException(String.format(
            "tickDuration: %d (expected: 0 < tickDuration in nanos < %d",
            tickDuration, Long.MAX_VALUE / wheel.length));
    }
 
    if (duration < MILLISECOND_NANOS) {
        logger.warn("Configured tickDuration {} smaller then {}, using 1ms.",
                    tickDuration, MILLISECOND_NANOS);
        this.tickDuration = MILLISECOND_NANOS;
    } else {
        this.tickDuration = duration;
    }
 
    // 通过线程工厂创建时间轮线程
    workerThread = threadFactory.newThread(worker);
 
    leak = leakDetection || !workerThread.isDaemon() ? leakDetector.track(this) : null;
 
    this.maxPendingTimeouts = maxPendingTimeouts;
 
    // 条件成立：时间轮实例的数量超过64
    if (INSTANCE_COUNTER.incrementAndGet() > INSTANCE_COUNT_LIMIT &&
        WARNED_TOO_MANY_INSTANCES.compareAndSet(false, true)) {
        // 打印日志进行提醒
        reportTooManyInstances();
    }
}

在HashedWheelTimer的构造方法中，主要会做下面几点：

• 进行时间轮数组的初始化，数组长度为时间轮大小为大于等于 ticksPerWheel 的第一个 2 的幂，和 HashMap的数组初始化类似
• 通过线程工厂创建出时间轮线程
• 检查HashedWheelTimer的实例数量是否超过了64，如果超过了则通过打印日志进行提醒

往HashedWheelTimer中添加延时任务 

public Timeout newTimeout(TimerTask task, long delay, TimeUnit unit) {
    checkNotNull(task, "task");
    checkNotNull(unit, "unit");
 
    long pendingTimeoutsCount = pendingTimeouts.incrementAndGet();
 
    // 条件成立：说明等待执行的延迟任务已经达到上限了
    if (maxPendingTimeouts > 0 && pendingTimeoutsCount > maxPendingTimeouts) {
        pendingTimeouts.decrementAndGet();
        throw new RejectedExecutionException("Number of pending timeouts ("
                                             + pendingTimeoutsCount + ") is greater than or equal to maximum allowed pending "
                                             + "timeouts (" + maxPendingTimeouts + ")");
    }
 
    start();
 
    // Add the timeout to the timeout queue which will be processed on the next tick.
    // During processing all the queued HashedWheelTimeouts will be added to the correct HashedWheelBucket.
    long deadline = System.nanoTime() + unit.toNanos(delay) - startTime;
 
    // Guard against overflow.
    if (delay > 0 && deadline < 0) {
        deadline = Long.MAX_VALUE;
    }
    HashedWheelTimeout timeout = new HashedWheelTimeout(this, task, deadline);
    timeouts.add(timeout);
    return timeout;
}

public Timeout newTimeout(TimerTask task, long delay, TimeUnit unit) {
    checkNotNull(task, "task");
    checkNotNull(unit, "unit");
 
    long pendingTimeoutsCount = pendingTimeouts.incrementAndGet();
 
    // 条件成立：说明等待执行的延迟任务已经达到上限了
    if (maxPendingTimeouts > 0 && pendingTimeoutsCount > maxPendingTimeouts) {
        pendingTimeouts.decrementAndGet();
        throw new RejectedExecutionException("Number of pending timeouts ("
                                             + pendingTimeoutsCount + ") is greater than or equal to maximum allowed pending "
                                             + "timeouts (" + maxPendingTimeouts + ")");
    }
 
    start();
 
    // Add the timeout to the timeout queue which will be processed on the next tick.
    // During processing all the queued HashedWheelTimeouts will be added to the correct HashedWheelBucket.
    long deadline = System.nanoTime() + unit.toNanos(delay) - startTime;
 
    // Guard against overflow.
    if (delay > 0 && deadline < 0) {
        deadline = Long.MAX_VALUE;
    }
    HashedWheelTimeout timeout = new HashedWheelTimeout(this, task, deadline);
    timeouts.add(timeout);
    return timeout;
}

可以看到通过newTimeout方法往HashedWheelTimer中添加延时任务的时候，会先去判断一下当前HashedWheelTimer实例中有多少延时任务在等待被执行调度，如果超过了指定的数量（该数量通过构造方法的maxPendingTimeouts参数指定），那么就会抛出异常。

        接着会去执行start方法，在start方法中主要做两件事，一个是对HashedWheelTimer的状态进行初始化，另一个是等待startTime属性的初始化，如果调用newTimeout添加延时任务的时候时间轮线程还没启动，那么此时就会通过CountDownLatch.await进行阻塞，当时间轮线程启动完之后，startTime就会被赋与当前时间，并且再通过CountDownLatch.countdown去唤醒调用newTimeout的线程。这样做的目的就是为了在添加延时任务的时候能够获取到时间轮线程的启动时间，为什么一定要获取到这个时间呢？因为既然要实现延时功能，那么就肯定是需要有个相对时间来计算延时任务的调度时间，而时间轮会一直在跑，在跑的过程中再去判断每一个延时任务是否到达调度时间了，而这个判断就需要依赖时间轮线程跑的时候与延时任务用的是同一个相对时间。

        接着根据当前时间+延迟时间-startTime去得到该延迟任务相对于startTime的延迟时间，最后通过HashedWheelTimeout把延迟时间和TimerTask进行包装然后放到普通任务队列中

时间轮线程运行过程

在HashedWheelTimer中有一个Worker内部类，该内部类实现了Runnable接口，其实它就是时间轮线程执行的任务，下面是它的run方法：

public void run() {
    // 初始化时间轮线程的启动时间
    startTime = System.nanoTime();
    if (startTime == 0) {
        // We use 0 as an indicator for the uninitialized value here, so make sure it's not 0 when initialized.
        startTime = 1;
    }
 
    // Notify the other threads waiting for the initialization at start().
    startTimeInitialized.countDown();
 
    do {
        // 获取到下一个时刻的起始时间
        final long deadline = waitForNextTick();
        if (deadline > 0) {
            // 计算出当前时刻的索引下标
            int idx = (int) (tick & mask);
            // 处理过期的任务
            processCancelledTasks();
            // 根据idx从时间轮数组中获取到对应的HashedWheelBucket
            HashedWheelBucket bucket =
            wheel[idx];
            // 把普通队列中的延时任务迁移到时间轮数组中
            transferTimeoutsToBuckets();
            // 执行对应的HashedWheelBucket中的HashedWheelTimeout链表
            bucket.expireTimeouts(deadline);
            // 时钟指针+1
            tick++;
        }
    }
    // 只要时间轮没有关闭，则这个while就一直循环下去
    while (WORKER_STATE_UPDATER.get(HashedWheelTimer.this) == WORKER_STATE_STARTED);
 
    // Fill the unprocessedTimeouts so we can return them from stop() method.
    for (HashedWheelBucket bucket: wheel) {
        bucket.clearTimeouts(unprocessedTimeouts);
    }
    for (;;) {
        HashedWheelTimeout timeout = timeouts.poll();
        if (timeout == null) {
            break;
        }
        if (!timeout.isCancelled()) {
            unprocessedTimeouts.add(timeout);
        }
    }
    processCancelledTasks();
}

可以看到，在run方法中，一开始就会去给startTime进行赋值初始化，初始化完毕之后就调用CountDownLatch.countdown方法，这里就和上面newTimeout方法对应上了，接着关键的核心逻辑在do...while循环中，我们下面看下在这个循环中主要做了什么

（1）时钟拨动 

private long waitForNextTick() {
    // 计算出到达下一个时刻的相对时间
    long deadline = tickDuration * (tick + 1);
    for (;;) {
        // 计算出时间轮线程已经执行了多长时间
        final long currentTime = System.nanoTime() - startTime;
        // deadline - currentTime这里就表示当前离下一个时刻还差多少时间
        // +999999的目的是为了让任务不被提前执行，比如deadline - currentTime = 2000002，2000002/1000000 = 2ms
        // 2ms明显就是提前执行了，所以加上999999就可以计算出3ms（很明显netty的时间轮宁可任务延迟执行也不要任务提前执行）
        long sleepTimeMs = (deadline - currentTime + 999999) / 1000000;
 
        // 条件成立：说明此时已经到达了下一个时刻了
        if (sleepTimeMs <= 0) {
            if (currentTime == Long.MIN_VALUE) {
                return -Long.MAX_VALUE;
            } else {
                return currentTime;
            }
        }
 
        // 兼容 Windows 平台，因为 Windows 平台的调度最小单位为 10ms，如果不是 10ms 的倍数，可能会引起 sleep 时间不准确
        // See https://github.com/netty/netty/issues/356
        if (PlatformDependent.isWindows()) {
            sleepTimeMs = sleepTimeMs / 10 * 10;
            if (sleepTimeMs == 0) {
                sleepTimeMs = 1;
            }
        }
 
        try {
            // 睡眠一段时间，等待下一个时刻的到来
            Thread.sleep(sleepTimeMs);
        } catch (InterruptedException ignored) {
            if (WORKER_STATE_UPDATER.get(HashedWheelTimer.this) == WORKER_STATE_SHUTDOWN) {
                return Long.MIN_VALUE;
            }
        }
    }
}

在该方法中会去根据时钟指针tick计算出时钟已经走了多长时间，然后再计算出时间轮线程已经运行的时间，两个时间相减就是当前离下一个时刻还剩多少时间了，此时让时间轮线程睡眠这段时间，当睡眠过后，如果指针走过的时间小于等于线程走过的时间，就表示这段时间就到达下一个时钟回拨点了，最后就返回当前时间轮线程的运行时间

（2）迁移延时任务到时间轮数组

private void transferTimeoutsToBuckets() {
    // 在每个时钟刻度中最多只迁移100000个延迟任务，以防止时间轮线程在迁移过程中耗费太多时间，从而导致添加进行的延时任务已经成为过时的任务
    for (int i = 0; i < 100000; i++) {
        HashedWheelTimeout timeout = timeouts.poll();
        if (timeout == null) {
            // 队列中没有延时任务了，跳出循环
            break;
        }
 
        // 跳过已取消的延时任务
        if (timeout.state() == HashedWheelTimeout.ST_CANCELLED) {
            // Was cancelled in the meantime.
            continue;
        }
 
        // 计算出该延时任务要走多少个时钟刻度才能执行
        long calculated = timeout.deadline / tickDuration;
        // 计算当前任务到执行还需要经过几圈时钟拨动
        timeout.remainingRounds = (calculated - tick) / wheel.length;
 
        final long ticks = Math.max(calculated, tick); // Ensure we don't schedule for past.
        int stopIndex = (int) (ticks & mask);
 
        HashedWheelBucket bucket = wheel[stopIndex];
        bucket.addTimeout(timeout);
    }
}

该方法会从普通任务队列中最多获取100000个延时任务，然后进行遍历

long calculated = timeout.deadline / tickDuration;

首先会去计算出延时任务需要走多少个时钟刻度才能被执行，也就是计算出calculated的大小

timeout.remainingRounds = (calculated - tick) / wheel.length;

 计算出这个延时任务的执行时间与时间轮当前时刻差了多少圈

final long ticks = Math.max(calculated, tick); // Ensure we don't schedule for past.
int stopIndex = (int) (ticks & mask);

 最后得到这个延时任务在时间轮中对应的槽，但是这里需要把calculated与tick进行比较取出最大值，为什么要对calculated和tick进行比较呢？通常来说calculated大于或等于tick的，那什么时候calculated会比tick要小呢？答案就是此时从队列中获取到的是上一个时刻的延迟任务，因为在每一个时刻中只会从队列中获取100000个延迟任务，如果队列中的延时任务超过了100000，那么剩下的延时任务就只能在下一个时刻中被获取到了，此时在下一个时刻中计算出来的calculated就会比tick小了，那么要怎么处理这些延时任务呢？此时就可以把这些延时任务放到时间轮数组对应tick的槽中即可，那么当前时就可以去执行上一个时刻遗留下来的延时任务了

（3）执行当前时刻的延时任务 

public void expireTimeouts(long deadline) {
HashedWheelTimeout timeout = head;
 
// process all timeouts
while (timeout != null) {
    HashedWheelTimeout next = timeout.next;
    // 条件成立：说明该延迟任务需要被执行了
    if (timeout.remainingRounds <= 0) {
        // 从链表中移除该延迟任务，并返回下一个延迟任务
        next = remove(timeout);
        // 执行该延迟任务
        if (timeout.deadline <= deadline) {
            timeout.expire();
        } else {
            // The timeout was placed into a wrong slot. This should never happen.
            throw new IllegalStateException(String.format(
                "timeout.deadline (%d) > deadline (%d)", timeout.deadline, deadline));
        }
    }
        // 条件成立：说明当前还未轮到该延迟任务执行，但是已经被取消了
    else if (timeout.isCancelled()) {
        next = remove(timeout);
    }
        // 条件成立：说明当前还未轮到该延迟任务执行
    else {
        // 时间轮圈数-1
        timeout.remainingRounds --;
    }
    timeout = next;
}
}

通过前面的操作就可以获取到当前时刻的HashedWheelBucket对象，然后遍历里面的延迟任务链表，在遍历的时候会去判断这个延迟任务时候是当前这一轮的，如果不是的话就把圈数-1，反之就表示需要执行这个延时任务 

（4）时钟指针+1，重复上面的过程 

            do {
                // 获取到下一个时刻的起始时间
                final long deadline = waitForNextTick();
                if (deadline > 0) {
                    // 计算出当前时刻的索引下标
                    int idx = (int) (tick & mask);
                    // 处理已取消的任务
                    processCancelledTasks();
                    // 根据idx从时间轮数组中获取到对应的HashedWheelBucket
                    HashedWheelBucket bucket = wheel[idx];
                    // 把普通队列中的延时任务迁移到时间轮数组中
                    transferTimeoutsToBuckets();
                    // 执行对应的HashedWheelBucket中的HashedWheelTimeout链表
                    bucket.expireTimeouts(deadline);
                    // 时钟指针+1
                    tick++;
                }
            }
            // 只要时间轮没有关闭，则这个while就一直循环下去
            while (WORKER_STATE_UPDATER.get(HashedWheelTimer.this) == WORKER_STATE_STARTED);

在上面的步骤走完之后，时钟指针+1，然后再判断时间轮的状态是否关闭的了，如果没有则重复上面的流程

Netty时间轮的缺点

Netty的时间轮是单线程的，所以如果在执行延时任务的过程中阻塞了，那么就会影响后面的延时任务的执行。同时它也不适合时间跨度范围很大的场景，比如往时间轮中扔很多的延时十几天时间的任务，这样这些延时任务在这期间都会以链表的形式存在于时间轮数组中，从而一直占用JVM内存

Netty时间轮与xxl-job时间轮的比较 

• Netty的时间轮是先等到这个时刻结束之后再去把这个时刻的任务捞出来进行调度，而xxl-job则相反，它是直接就把当前时刻的任务执行完了之后，再去等到下一个时刻的到来
• xxl-job的时间轮并不支持任意延时时间的延时任务，最多只能支持延时60s之内的延时任务，因为它没有对时间轮圈数进行处理（内部是一个map，延时1s的任务和延时61s的任务会产生hash冲突，就会导致执行1s的任务的同时还会执行61s的任务），而Netty时间轮的设计则支持了这一点，对每一个任务通过增加一个remainingRounds属性去记录该任务的相当于当前时刻的时间轮圈数，从而在时间轮执行每一个槽的时候去进行判断是否是当前时刻的任务
• xxl-job的时间轮如果在某一个时刻的任务调度时间超过了2s，比如说3s，那么就会丢失掉一个时刻的任务没有被调度到，也就是说xxl-job的时间轮最多只能让一个时刻的任务调度不超过2s，而Netty的时间轮则没有这个担忧，不管一个时刻内的延时任务被调度的时长超过了多久，它都能不丢失后面的每一个延时任务的调度（当然了，这样的话后面的延时任务的执行时间也就会被延后了）
• 在xxl-job的时间轮中，是直接把延时任务放到时间轮容器中的，而Netty的时间轮则是在当前时刻结束之后，才去队列中把延时任务搬到时间轮容器中，这样进行比较的话，xxl-job的时间轮线程其实就比较纯粹了，因为它只干执行延时任务的事，而Netty的时间轮线程还要干对延时任务进行迁移到时间轮容器的事情

Netty时间轮的最佳使用方式

建议对Netty时间轮按模块去创建实例，因为每一个模块的业务不同，导致创建的时间轮参数则不同，特别是tickDuration这个参数，如果说某一个模块的延时任务平均的延时执行时间大概是30s，那么我们就可以设置tickDuration为30s，这样的话就不会让Netty的时间轮线程一直处于空转的状态（如果tickDuration设置为1s，则在30s内就空转30次）。比如我们可以以枚举的方式去创建Netty时间轮实例

public enum HashedWheelTimerInstance {
 
    // 订单模块
    ORDER(30, TimeUnit.SECONDS, 64),
 
    // 用户模块
    USER(1, TimeUnit.MINUTES, 64);
 
    // 时间轮实例
    private final HashedWheelTimer wheelTimer;
 
    HashedWheelTimerInstance(long tickDuration, TimeUnit timeUnit, int ticksPerWheel) {
        wheelTimer = new HashedWheelTimer(r -> {
            Thread t = new Thread(r);
            t.setUncaughtExceptionHandler((t1, e) -> System.out.println(t1.getName() + e.getMessage()));
            t.setName("-HashedTimerWheelInstance-");
            return t;
        }, tickDuration, timeUnit, ticksPerWheel);
    }
 
    public HashedWheelTimer getWheelTimer() {
        return wheelTimer;
    }
}