welllog

在bucket的Flush函数中会首先移除该bucket中的timer，移除后再添加到新的bucket中或执行,此时在还未加到新bucket时如果并发的对某个timer stop，因为timer的bucket为nil,导致并没有停止

Stop循环条件是timer的bucket != nil, 但是flush中的for循环会先把timer的bucket置为nil, 此时timer stop由于bucket为nil不会执行。flush后面的reinsert再把timer插入 ，不就没有停止么。

第一个问题，退出时也需要切换sleeping值的状态就可以了吧，跟加个status的状态差不错，只不过status明确告知错误比无意义的添加要好些。 第二个问题，flush时不设为nil不太好处理。Stop方法的循环中本身就是调用的Remove方法，除非Stop方法中的移除才将timer的bucket置为空。但仍然不行，假设并发时，flush中链表遍历完后再Stop，再执行flush中的reinsert将该timer插入一个新的bukcet，stop仍然无效。最好是加个字段表明timer停止了，但这就变成惰性删除了，一些原有设计就没必要了。 惰性删除版本可以见https://github.com/welllog/timewheel

不清楚这个TODO是否指 并发时，add设置桶的过期时间后，又被flush中设为-1覆盖的情况 你PR里面写的curTime的下一个tick的timer，定位到该bucket。如果是advanceClock调整currentTime先于add获取currentTime执行，则add应该不会定位到该bucket吧。如果add获取到旧的currentTime，advanceClock再调整时间，应该才会定位到该bucket,add操作中的设置bucket过期时间跟flush中将过期时间设为-1无法保证哪个先操作，flush遍历链表过后add再实际插入并设置过期时间，flush中的设为-1再执行 就会出现你说的问题。将flush中的设置过期时间放入锁中，flush先于add执行没问题，在add中实际添加过后，再执行flush，但add中的设置过期时间这一操作仍然跟flush中的设置过期时间没有互斥关系，仍然不能保证谁先执行吧 不知道我推理得对不

add中实际添加到bucket后，再执行flush中的遍历已经能够获取到之前的添加timer了，此时哪个设置过期时间不重要了。上面说错了。

ErrorController确实并不会执行postDispatch和dispatchLoopShutdown，这个问题会解决么

还是没什么意义，fetch本身已经是从一个带缓冲的channel中获取即已经是异步，多增加的这个channel看不出有什么解藕。因为consume消费慢了会导致channel背压，自然会导致调用FetchMessage的生产者goroutine阻塞，再反向传递到kafka-go的自有缓冲channel。 目前这种实现，并发从一个channel拿再并发写入另一个channel,再并发从最后这个channel拿数据consume，相当于凭白多了一轮并发写和并发读，损耗了性能

> （ ??,加不加channel跟业务层并发有啥关系，在go-queue这个框架的封装里取channel里面的数据跟调用fetch有啥区别，你再看看kafka-go源码，kafka-go这个库已经偏高层api了，很多细节已经实现好了

I had the same problem. Refer to the example in rewriting the unit test as follows: ` testLLM1 := &testLanguageModel{expResult: "In the year 3000, chickens have taken over the world"}...

已修改