Redisson事件循环关闭异常问题分析与解决

问题背景

在使用Redisson客户端(版本3.28.0)连接ElastiCache Redis 7.1.0时，系统出现了"Failed to submit a listener notification task. Event loop shut down?"的错误。这个错误表现为事件执行器(event executor)在终止后仍然尝试提交监听器通知任务，导致RejectedExecutionException异常。

错误现象

从堆栈跟踪可以看出，当Netty的Channel关闭时，系统尝试通过事件执行器通知监听器，但此时事件执行器已经终止，无法接受新任务。具体表现为：

java.util.concurrent.RejectedExecutionException: event executor terminated

根本原因分析

经过深入代码分析，发现问题出在Redisson的MasterSlaveConnectionManager实现中。该管理器在关闭连接时，错误地将graceful shutdown的超时参数(timeoutInNanos)计算为0，导致事件循环没有足够时间完成现有任务就立即关闭。

关键问题点在于以下代码逻辑错误：

timeoutInNanos = Math.max(0, timeoutInNanos - (System.nanoTime() - startTime));

这段代码本意是计算剩余的graceful shutdown时间，但由于错误的计算方式，最终导致timeoutInNanos被设置为0。进而使得quietPeriod(静默期)也被设置为0，导致事件循环立即终止，而没有等待正在执行的任务完成。

解决方案

修复方案是正确计算graceful shutdown的超时时间。具体修改包括：

1. 确保timeoutInNanos正确计算剩余时间
2. 保持quietPeriod和timeout的合理值，让事件循环有足够时间完成现有任务

修复后的代码应该确保：

• 在关闭连接时，给予事件循环足够时间(默认2秒静默期和10秒超时)完成现有任务
• 正确计算剩余graceful shutdown时间，避免过早强制终止

验证方法

为了验证修复效果，可以添加如下测试用例：

@Test
public void testShutdownQuietPeriod() {
    long quietPeriod = TimeUnit.SECONDS.toMillis(1);
    long timeOut = quietPeriod + TimeUnit.SECONDS.toMillis(1);
    RedissonClient r = createInstance();
    long startTime = System.currentTimeMillis();
    r.shutdown(quietPeriod, timeOut, TimeUnit.MILLISECONDS);
    long shutdownTime = System.currentTimeMillis() - startTime;
    
    Assertions.assertTrue(shutdownTime > quietPeriod);
}

这个测试验证了客户端在关闭时确实等待了指定的静默期时间，确保现有任务能够完成。

总结

Redisson的这个bug会导致在高并发或复杂场景下，事件循环被过早关闭，进而引发任务提交失败。对于生产环境来说，这种问题可能会导致监听器回调丢失、资源未正确释放等问题。通过修复graceful shutdown的时间计算逻辑，可以确保事件循环正确完成现有任务后再终止，提高系统的稳定性和可靠性。

该问题已在Redisson后续版本中得到修复，建议受影响的用户升级到最新版本以获得更稳定的连接管理行为。