C# 版的SnowWorkerM1.cs文件第109行-第116行是个BUG吗？ about idgenerator HOT 5 CLOSED

逻辑上讲，应该用 options.MaxSeqNumber。
从数值上讲，1<<SeqBitLength-1，是对的。目前DefaultIdGenerator 和 M1中都做了处理，后续可以优化一下，集中一处处理。

from idgenerator.

因为MaxSeqNumber和options.MaxSeqNumber的默认值都是0，所以用户让options.MaxSeqNumber保持默认值0，代码会正常工作。修改为0以外的值，就会发现该配置无法生效。我没有运行代码验证过这点，但理应如此。

这个库做的非常棒。我打算将它集成到项目中。一直担心 并发过大 Id重复，把雪花漂移代码看了2天。发现如果在一毫秒内生成的Id超过上限，程序就会停止生成Id，直到下一个毫秒到来。此设计是非常好的。但看到您写的TODO：
// TODO: 在漂移终止，等待时间对齐时，如果发生时间回拨较长，则此处可能等待较长时间。可优化为：在漂移终止时增加时间回拨应对逻辑。（该情况发生概率低，暂不处理）

您是认为对于这种情况，还有一个没来得及实现的更好的处理方案吗？

from idgenerator.

因为MaxSeqNumber和options.MaxSeqNumber的默认值都是0，所以用户让options.MaxSeqNumber保持默认值0，代码会正常工作。修改为0以外的值，就会发现该配置无法生效。我没有运行代码验证过这点，但理应如此。

这个库做的非常棒。我打算将它集成到项目中。一直担心 并发过大 Id重复，把雪花漂移代码看了2天。发现如果在一毫秒内生成的Id超过上限，程序就会停止生成Id，直到下一个毫秒到来。此设计是非常好的。但看到您写的TODO： // TODO: 在漂移终止，等待时间对齐时，如果发生时间回拨较长，则此处可能等待较长时间。可优化为：在漂移终止时增加时间回拨应对逻辑。（该情况发生概率低，暂不处理）

您是认为对于这种情况，还有一个没来得及实现的更好的处理方案吗？

只能说是代码结构优化，逻辑上没有bug调整

from idgenerator.

善

from idgenerator.

因为MaxSeqNumber和options.MaxSeqNumber的默认值都是0，所以用户让options.MaxSeqNumber保持默认值0，代码会正常工作。修改为0以外的值，就会发现该配置无法生效。我没有运行代码验证过这点，但理应如此。

这个库做的非常棒。我打算将它集成到项目中。一直担心 并发过大 Id重复，把雪花漂移代码看了2天。发现如果在一毫秒内生成的Id超过上限，程序就会停止生成Id，直到下一个毫秒到来。此设计是非常好的。但看到您写的TODO： // TODO: 在漂移终止，等待时间对齐时，如果发生时间回拨较长，则此处可能等待较长时间。可优化为：在漂移终止时增加时间回拨应对逻辑。（该情况发生概率低，暂不处理）

您是认为对于这种情况，还有一个没来得及实现的更好的处理方案吗？

抱歉，之前有疏忽，对于你提出的【还有一个没来得及实现的更好的处理方案吗？】这个问题，之前没有回答。
今天再补充一下，关于【在漂移终止时增加时间回拨应对逻辑。（该情况发生概率低，暂不处理）】这个问题，是有一个更好的方案，不过由于漂移后再发生时钟回拨的概率极低极低，我就没有去处理它（因为当下的存在的问题，只是多等待一会让时间对其，并不会产生逻辑bug）。

from idgenerator.