在java日志记录中，要实现日志文件按大小滚动，最标准的做法是使用logback框架并配置 rollingfileappender。你需要指定一个 sizebasedtriggeringpolicy 作为触发策略，并配合 fixedwindowrollingpolicy 或 timebasedrollingpolicy 来管理文件的命名和保留数量。这样配置后，当日志文件大小达到设定阈值时，会自动触发滚动，生成新的日志文件，从而避免单个日志文件过大。
Logback中如何配置基于大小的滚动策略
要配置基于大小的滚动，必须在 logback.xml 中定义 appender，并在其中嵌套 rollingPolicy 和 triggeringPolicy。核心在于使用 SizeBasedTriggeringPolicy 类，它会在每次写入日志前检查当前文件大小是否超过 maxFileSize 属性设定的值。如果超过，就会触发滚动逻辑。
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="ROLLING" class="ch.qos.logback.classic.sift.SiftingAppender">
<!-- 这里以标准的 RollingFileAppender 为例 -->
</appender>
<appender name="FILE-ROLLING" class="ch.qos.logback.classic.rolling.RollingFileAppender">
<file>application.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
<fileNamePattern>application.%i.log.gz</fileNamePattern>
<minIndex>1</minIndex>
<maxIndex>3</maxIndex>
</rollingPolicy>
<triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
<maxFileSize>10MB</maxFileSize>
</triggeringPolicy>
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="FILE-ROLLING" />
</root>
</configuration>上述代码中，maxFileSize 设置为 10MB，意味着当 application.log 达到10兆字节时，滚动策略会被激活。FixedWindowRollingPolicy 使用索引 %i 来重命名旧文件，例如 application.1.log.gz，并且 maxIndex 为3表示最多保留3个历史文件，超出部分会被删除。这种组合确保了日志文件既受大小限制，又不会无限增长占用磁盘空间。
立即学习“Java免费学习笔记（深入）”；
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
与时间滚动结合时的注意事项
虽然问题主要关注大小滚动，但在实际生产中，通常会将大小滚动与时间滚动结合使用，即 TimeBasedRollingPolicy 同时承担滚动和清理的职责。这种情况下，配置方式会有所不同，SizeBasedTriggeringPolicy 依然用于触发滚动，但 fileNamePattern 需要包含时间模式（如 %d{yyyy-MM-dd}）和索引模式（如 %i）。这种混合模式允许日志按天归档，同时在每天的文件内再按大小分割。
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="COMBINED-ROLLING" class="ch.qos.logback.classic.rolling.RollingFileAppender">
<file>application.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- 包含日期和索引，实现按天和按大小双重滚动 -->
<fileNamePattern>application.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
<maxHistory>30</maxHistory>
<totalSizeCap>10GB</totalSizeCap>
</rollingPolicy>
<triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
<maxFileSize>50MB</maxFileSize>
</triggeringPolicy>
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="DEBUG">
<appender-ref ref="COMBINED-ROLLING" />
</root>
</configuration>在这个混合配置中，TimeBasedRollingPolicy 的 fileNamePattern 包含了 %d{yyyy-MM-dd} 和 %i。这意味着每天会创建一个新的日志文件基础名，而当天内的日志如果超过 50MB（由 SizeBasedTriggeringPolicy 控制），则会通过 %i 进行编号分割，如 application.2023-10-27.1.log.gz。maxHistory 保留了30天的日志，totalSizeCap 限制了所有日志文件的总大小为10GB。这种配置比单纯的固定窗口滚动更灵活，适合长期运行的服务。
当日志文件达到阈值但未触发滚动的条件是什么
在Logback的实现中，SizeBasedTriggeringPolicy 的触发检查是在每次日志事件被处理时进行的。然而，如果日志级别设置不当，或者没有日志事件发生，即使文件接近阈值，也不会触发滚动。具体来说，只有当有日志消息被写入到该 Appender 时，才会检查当前文件大小。如果应用处于空闲状态，没有产生任何日志输出，文件将保持原样，不会进行滚动操作。此外，如果 maxFileSize 设置得非常大，超过了系统单次写入的限制或导致内存溢出风险，也可能间接影响滚动的及时性，但这属于极端情况。正常情况下，只要产生日志且达到阈值，滚动就会立即发生。
