怎么利用 java.util.logging.FileHandler 配置日志文件的循环滚动记录策略

怎么利用 ja va.util.logging.FileHandler 配置日志文件的循环滚动记录策略

FileHandler 的日志滚动机制靠什么控制

说到Ja va原生日志框架里的ja va.util.logging.FileHandler，有件事得先明确：它本身并不支持按时间（比如每天）自动滚动日志文件。它的核心能力，其实就聚焦在“按文件大小+文件数量”这套循环覆盖策略上。这里的关键，是两个必须同时设置的参数：limit（单个文件最大字节数）和count（最多保留几个历史文件）。

一个常见的坑是，开发者只设置了limit，却忘了count。结果呢？日志文件写满预设大小后，并不会如预期般滚动，反而可能直接抛出ja va.io.IOException: Stream closed，或者干脆静默失败。原因在于，虽然默认count == 1，但框架的初始化逻辑要求，必须显式传入一个大于0的count值，才会真正激活那套轮转机制。

• limit = 0：这意味着禁用大小限制，日志文件会一直写下去，永不滚动（除非你手动去关闭或重新打开）。
• count = 1：这种情况下，日志只会写入主文件，不会生成任何带编号的副本（比如.%g），滚动功能自然也就失效了。
• count > 1：这才是启用滚动的正确姿势。旧的日志文件会被重命名为mylog.1、mylog.2……以此类推，最老的那个文件则会被自动删除。

如何正确构造支持滚动的 FileHandler 实例

想让FileHandler乖乖滚动起来，构造实例时就得用对方法。必须使用那个带4个参数或者5个参数的构造函数，把limit和count这两个关键值明确传进去。还有一点至关重要：记得把append参数设为true，这样才能确保日志是持续追加到文件末尾的。否则，每次JVM重启，都会把原来的日志文件清空重来。

Handler handler = new FileHandler(
    "logs/app.log",   // pattern，支持 %g（序号）、%u（唯一数）
    10 * 1024 * 1024, // limit：10MB
    5,                // count：最多保留 5 个文件
    true              // append：追加模式
);

这里有个细节值得注意：pattern参数（也就是文件路径模式）里如果包含了%g，那么滚动时就会自动生成app.log.0、app.log.1这样带序号的文件名。如果没包含%g，虽然内部依然会通过重命名来实现滚动，但所有文件在外观上都叫app.log，序号就看不到了。

立即学习“Ja va免费学习笔记（深入）”；

• 推荐使用"logs/app.%g.log"这样的模式，既方便人工识别不同时期的日志文件，也便于和系统工具（如logrotate）配合管理。
• 如果把limit设得太小（比如只有1KB），会导致日志滚动异常频繁，随之而来的大量文件重命名操作，可能会对I/O性能造成不小的影响。
• 在Windows系统下，文件路径中的分隔符建议使用正斜杠/，或者双反斜杠\\，这样可以有效避免一些不必要的转义问题。

为什么日志没滚动？排查这三处硬性条件

即便代码写得明明白白：new FileHandler(..., 1048576, 3, true)，有时候日志文件就是纹丝不动，不按计划滚动。问题出在哪？核心原因在于，滚动的触发不仅依赖于正确的配置，还和日志记录的实际行为以及Handler本身的状态紧密相关。

• 首先，Handler必须已经通过setLevel(Level.ALL)设置了合适的日志级别，并且没有被close()方法关闭过。一旦被关闭，它可不会自动重新打开。
• 其次，必须有真实的日志内容被写入（比如执行了logger.info("x")）。空跑程序，没有日志输出，是不会触发任何大小检查的。
• 最后，每次写入日志前，Handler内部都会检查当前文件大小是否已经达到或超过了limit。如果达到了，它会执行一个包含关闭当前流、重命名旧文件、打开新文件的操作序列。需要注意的是，这个过程并非原子操作，在高并发场景下，可能会因为文件锁冲突等原因导致失败，从而跳过滚动（在Windows系统上尤其需要注意这个问题）。

一个典型的错误现象就是抛出IOException: The process cannot access the file because it is being used by another process。这通常发生在多线程或者多个JVM实例试图写入同一个日志文件时。FileHandler在设计上并不支持跨进程的日志文件共享。

替代方案：何时该放弃原生 FileHandler

那么，什么时候应该考虑换掉原生的FileHandler呢？当你需要更高级的功能时，比如按天自动滚动日志、对历史日志进行压缩归档、实现异步刷盘以提升性能，或者输出结构化的JSON格式日志，FileHandler就显得有些力不从心了。它没有内置压缩功能，不支持yyyy-MM-dd这类时间模板命名，也无法在滚动发生时执行自定义的钩子函数（比如通知运维人员）。

在实际的项目中，遇到这些复杂需求时，更常见的做法是转向其他成熟的日志框架：

• 使用Logback框架的RollingFileAppender配合TimeBasedRollingPolicy，可以轻松实现基于时间的滚动策略。
• 或者选择Log4j2的RollingRandomAccessFileAppender，它在性能和功能上都有不错的表现。
• 如果仍想留在ja va.util.logging体系内，也可以考虑配合使用第三方的Handler实现，例如在日志达到SEVERE级别时发送邮件告警，或者通过自定义的Handler来实现定时归档等高级功能。

总而言之，原生的FileHandler其滚动能力定位非常清晰：足够轻量，适合工具类或嵌入式等简单场景，核心只管“大小”和“数量”这两件事。一旦日志规模增长，或者运维提出了更精细的管理要求，它的能力边界也就非常明显了——剩下的，都得靠自己来补充完善。