Spring的Log4J配置器Log4jWebConfigurer介绍

1. Logj4简介

    Log4j是Apache大旗下的一个子项目，它能够用来重定向应用日志文件的输出流，不管咱们想将日志文件输出到控制台仍是网络仍是其余地方，均可以经过logj4来配置，若是咱们的应用里面引入的Spring框架技术，咱们能够经过Spring来初始化logj4的配置文件信息，下面2，3节是对Spring文档的一些翻译第4节是做者本身对一些问题的见解：

2. Log4jWebConfigurer及主要配置参数

    Log4jWebConfigurer是一个方便的自定义log4j web环境的初始化配置工具类，由spring util包提供，能够配置web应用的日志文件输出流路径，提供自动刷新检查的选项（这一般用于运行时日志配置的变动）。警告：假设一个展开的WAR包，同时会加载配置文件和写日志文件。若是你不想展开你的WAR包或者你不须要应用级别的日志文件存放在WAR目录，那么你就不要在应用中配置log4j（所以也不须要使用Log4jConfigListener或Log4jConfigServlet）。做为替代，你可使用全局的，虚拟机范围的log4j的配置（例如在jBoss容器中）,或者JDK1.4提供的java.util.logging（这是个全局工具）。

在Servet上下文级别支持三个初始化参数，经过web.xml中的context-param参数配置。

第一个参数：log4jCongLocation

指定logj4配置文件的位置，能够经过classpath配置（例如：classpath:myLog4j.properties），也能够经过绝对路径配置（如：C:/log4j.properties）或相对路径配置，/WEB-INF/log4j.properties。若是没有指定，默认的log4j初始化配置将会使用classpath路径下的log4j.properties或者log4j.xml文件。

第二个参数：log4jRefreshInterval

两次检查配置的时间间隔，单位是毫秒，若是没有配置刷新时间间隔，log4j将不会在运行时刷新配置，这将不会启动log4j的看门狗服务。

第三个参数：log4jExposeWebAppRoot

Web应用根系统属性是否被暴露，使得能够得到日志文件相对于web应用的根目录路径。默认值是”true”，能够设置为”false”来禁止暴露web应用的根系统属性。下面来看看详细的介绍，怎样使用这个系统属性来配置日志文件的路径。

注意：initLogging方法必须在使用log4j的其余spring组件启动以前调用，所以logj4的配置监听器在web.xml中的位置将会在spring其余组件启动监听器以前。

3. log4j配置看门狗服务

    log4j的看门狗服务是由一个线程实现的，看门狗服务会异步的检查对应时间戳点的日志配置文件是否有变动，检查时间间隔参数来自用户的配置。同时要知道1000毫秒，也就是1秒中的检查时间间隔来检查日志级别的配置变动方案是不可行的，同时实际运行时检查时间间隔相对于配置也有必定的时间偏差，请不要过度纠结。

警告：：Logj4的看门狗服务线程将不会终止直到虚拟机进程中止。实际上，看门狗线程并不能经过LogManager来终止。所以，咱们并不建议在j2ee应用的生产环境上使用配置文件刷新服务，若是不须要定时刷新配置文件的话看门狗服务就不会被唤醒，由于即便应用关闭，看门狗线程也不会被shutdown，这个时候有可能会形成资源泄露。

默认状况下，这个配置器会自动配置web应用的根系统目录，在日志文件配置中用${key}替代，也能够配置相对路径。默认的系统属性key是webapp.root，在log4j配置文件中像下面这样使用：log4j.appender.myfile.File=${webapp.root}/WEB-INF/demo.log

同时每一个web应用应该指定一个惟一的web上下文参数webAppRootKey，例如：

"webAppRootKey = "demo.root”:

log4j.appender.myfile.File=${demo.root}/WEB-INF/demo.log

警告：一些容器，像tomcat这种，将不会为每一个web应用保存一份独立的系统参数，所以你须要为每一个web应用配置一个上下文参数webAppRootKey来避免冲突，其余应用像，Resin这种会自动隔离每一个web应用的系统属性，，所以在这种容器中可使用默认的webAppRootKey。

4. JVM级别的线程的一些问题

    上面看门狗服务的介绍引出了一个问题，当咱们须要使用看门狗服务来在运行时为咱们刷新日志配置的时候也为应用埋下了一个隐患。举个例子，咱们使用tomcat容器来运行咱们的web应用，而咱们web应用的线程依赖tomcat线程，这是由tomcat架构决定的，tomcat应用能够看作是一个依赖于虚拟机的进程。当一个web应用启动的时候开启了如看门狗这样的一个线程，这个线程只能在虚拟机进程关闭的时候才可以关shutdown，若是在线程中分配了一些资源，如在ThreadLocal中存储一些对象信息，这些内存迟迟得不到释放，即便在应用shutdown关闭的时候也同样，由于这个时候tomcat进程还在，虚拟机进程还在。一种作法就是在进程中去配置一个钩子点，在应用进程挂掉的时候来假shutdown掉这个线程，固然之因此我说“假”字，是由于咱们不能回收一个线程资源，只可以清理掉线程引用的一些资源，至少这样能让内存回收工做交给垃圾回收器来处理，咱们不能回收线程。以后线程会由tomcat回收利用，用于其余web应用的调度。

转自：https://www.tuicool.com/articles/nuUVZr