Logback FixedWindowRollingPolicy仅生成22个日志文件的原因及疑问

1. 为何设置maxIndex=300却仅生成22个日志文件？ #

问题根源在于FixedWindowRollingPolicy源码中硬编码了private static int MAX_WINDOW_SIZE = 20，并且在setMaxIndex方法中会做校验：当你设置的窗口大小（maxIndex - minIndex + 1）超过20时，会自动将maxIndex截断为minIndex + MAX_WINDOW_SIZE - 1。

举个例子，若你默认minIndex=1，设置maxIndex=300，窗口大小计算为299，远超20，因此实际生效的maxIndex会被调整为1+20-1=20。最终生成的文件包括当前正在写入的活跃日志文件，加上log.1到log.20这20个滚动文件；若你的minIndex设为0，调整后的maxIndex为19，加上活跃文件和log.0到log.19，总数就会是22个，和你观察到的结果一致。

2. 为何较大窗口大小通常不可取？ #

Logback注释提到窗口大小超过20不是好主意，主要和性能开销、维护复杂度相关，尤其在低配置机器上风险更明显：

• IO性能瓶颈：大量日志文件会增加目录条目数量，在老旧文件系统（如ext3、FAT32）下，目录遍历、文件查找的耗时会显著增加，低配置机器本身IO能力弱，会进一步放大这个问题。
• 滚动操作阻塞：FixedWindow策略每次滚动时，需要批量重命名窗口内的文件（比如把log.19改名为log.20，log.18改名为log.19，直到完成所有索引递进）。窗口越大，重命名的文件越多，这个同步操作会阻塞日志写入，导致应用卡顿，低配置机器上阻塞时间会更长。
• 资源占用过高：维护大量文件的元数据（文件名、修改时间等）会消耗额外内存；后续清理、备份旧日志时，遍历几百个文件也会占用更多CPU和IO资源，挤压应用的运行资源。
• 维护复杂度提升：大量小文件会增加日志归档、排查问题的难度，比如定位某一时间点的日志需要查找更多文件，效率低下。

3. 实现固定大小+时间戳命名压缩日志的建议 #

FixedWindowRollingPolicy的核心逻辑是基于索引的窗口管理，并不适合直接扩展为时间戳命名的模式。更合理的方案是：

• 用SizeBasedTriggeringPolicy触发滚动：配置当日志文件达到30MB时触发滚动操作。
• 自定义RollingPolicy：在滚动时，将当前日志文件用ZipOutputStream压缩，并以log_yyyyMMdd_HHmmss.zip的格式命名（通过SimpleDateFormat生成时间戳），然后创建新的空白日志文件继续写入。

不需要基于FixedWindow扩展，因为时间戳命名的日志文件不需要索引管理，每个文件都是唯一的，完全可以脱离窗口逻辑实现。

内容的提问来源于stack exchange，提问作者Sorin Penteleiciuc