Log4J学习【二十一】常用的Appender之FileAppender

我们来继续考虑一下FileAppender，假设现在我们把产品已经部署完成，设置好FileAppender和Level，日志就慢慢的在文件中记录着。突然有一天，我们想要查看一下日志文件了，可能会发现几个问题：1，日志文件可能已经非常庞大了，打开非常缓慢，而且文件越大，做日志的速度会越来越慢。针对这种情况，可能大家很容易的就想到，我们能自己继承一下FileAppender，让文件到达一定的大小，就重新创建一个。要完成这样的功能，自己写代码也是不难的，但是Log4J也考虑到了这个问题，为我们提供了更方便的RollingFileAppender。
    首先，RollingFileAppender也能够将日志记录到文件中，并且可以当一个文件到达了指定大小后，把这个日志文件备份并重开一个日志文件。RollingFileAppender是继承自FileAppender，所以FileAppender那些配置项仍然能够使用，这个Appender自己提供了几个参数：
    MaximumFileSize：设置日志文件能达到的最大的容量，超过这个大小，日志文件就会备份并新开。注意，这个maximumFileSize的参数值是文件的大小值，是long型的。
    MaxFileSize：这个参数项也是用来设置日志文件能达到的最大的容量。但这个参数值传入的参数类型是String；在这个String中，可以允许通过使用KB，MB，或者GB来方便的指定文件的大小，这个参数比maximumFileSize方便的多。
    MaxBackupIndex：设置备份文件能够存在的最大索引号。要了解这个参数的作用，我们得先通过测试来看看RollingFileAppender的备份文件的方式，写一个小的测试代码：
log4j.rootLogger=DEBUG,file
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.conversionPattern=%r [%t] %p %c %x - %m%n
log4j.appender.file.file=log.log
log4j.appender.file.maxFileSize=10KB
    在配置文件中，我们设置文件最大的容量为10KB；然后我们来多记录一些日志：
@Test
public void testRollingFileAppender() {
    Logger logger = Logger.getLogger("cd.itcast");
    Logger barLogger = Logger.getLogger("cd.itcast.log");
    for (int i = 0; i < 100; i++) {
        logger.warn("logger warn");
        logger.debug("logger debug");
        barLogger.info("bar logger info");
        barLogger.debug("bar logger debug long long ");
    }
}
    在这里，我们循环了100次日志记录，运行测试：
    可以看到，生成了两个日志文件，名为log.log和log.log.1，分别打开这两个文件，可以看到，在log.log.1日志文件中的%r，都是从0开始的，而log.log中的%r是从31开始的，那么我们很明显的可以知道，log.log文件是目前正在记录日志的文件，而log.log.1是已经达到文件大小上限的文件。Log4J会把已经达到最大值的日志文件后缀名修改为1,2,3,4等，并重开log.log，用来作为最新日志记录文件。是不是按照我们猜想的这样运行的呢？我们修改一下配置项：
log4j.appender.file.maxFileSize=1KB
    我们把文件最大设置为1KB，再次运行：
    可以看到，程序任然只生成了log.log和log.log.1，但是，打开文件之后，我们发现，两个日志文件中的%r都是94，换句话说，我们最开始记录的那些日志已经被删除了，Log4J只会为我们生成一个备份文件，这样设计不是很不合理么？其实，这个问题正是由于我们没有正确的设置MaxBackupIndex参数造成的，我们来重新配置一下：
log4j.appender.file.maxBackupIndex=100
    我们设置maxBackupIndex值为100，再次运行这个测试：
    可以看到，生成了很多log.log.N的文件，那么这个maxBackupIndex的作用就非常明显了，他用来设置最大备份文件的序号，如果备份文件的序号超过了这个数，那么更早的日志文件就被删除了。
    通过我们的测试代码，我们可以总结出RollingFileAppender的规律：
    首先创建file名字的文件：log.log；
    当log.log到达maxFileSize后，就把log.log备份为log.log.1，并且新开log.log文件；
    当log.log再次达到maxFileSize后，就依次把log.log.N重命名为log.log.N+1，即log.log.1就变成了log.log.2，log.log就变成了log.log.1；
    如果log.log.N+1超过了maxBackupIndex大小，就删除备份文件。

    可以看到，使用RollingFileAppender虽然可以将文件大小控制在一定的范围内，但是还是会造成一些问题：1，文件命名没有规律，可能会造成某一段时间的日志分散在两个日志文件中，2，从文件名中很难定位具体的日志信息。在真实的产品中，我们要监控日志，往往需要定位到某个具体的时间段里面的日志信息，使用RollingFileAppender就很难做到。Log4J也想到了这点，提供了DailyRollingFileAppender。