日志那点事儿——slf4j源码剖析

前言:

  说到日志,大多人都没空去研究,顶多知道用logger.info或者warn打打消息。那么commons-logging,slf4j,logback,log4j,logging又是什么关系呢?其中一二,且听我娓娓道来。

  手码不易,转载请注明_xingoo!

  涉及到的内容:日志系统的关系、Slf4j下载、源文件jar包的使用、Slf4j源码分析、JVM类加载机制浅谈

  首先八卦一下这个日志家族的成员,下面这张图虽然没有包含全部的内容,但是基本也涵盖了日志系统的基本内容,不管怎么说,先记住下面这张图:

  通过上面的图,可以简单的理清关系!

  commons-logging和slf4j都是日志的接口,供用户使用,而没有提供实现!

  log4j,logback等等才是日志的真正实现。

  当我们调用接口时,接口的工厂会自动寻找恰当的实现,返回一个实现的实例给我服务。这些过程都是透明化的,用户不需要进行任何操作!

  这里有个小故事,当年Apache说服log4j以及其他的日志来按照commons-logging的标准编写,但是由于commons-logging的类加载有点问题,实现起来也不友好,因此log4j的作者就创作了slf4j,也因此而与commons-logging两分天下。至于到底使用哪个,由用户来决定吧。

  这样,slf4j出现了,它通过简单的实现就能找到符合自己接口的实现类,如果不是满足自己标准的日志,可以通过一些中间实现比如上面的slf4j-log4j12.jar来进行适配。

  如此强大的功能,是如何实现的呢?

  

  slf4j下载

  首先为了查阅源码,这里先教大家如何使用开源的jar包!

  例如在官网:http://www.slf4j.org/download.html

  这里提供给我们两个版本,linux下的tar.gz压缩包,和windows下的zip压缩包。

  下载zip文件后解压,可以找到提供给我们的使用工具包。一般来说,这种开源的项目会为我们提供两种jar包,就拿slf4j(有人叫他,撒拉风four接,很有意思的名字)slf4j.jar、slf4j-source.jar:

  这里slf4j-api-xxx.jar就是它的核心包,而slf4j-api-xxx-source.jar是它的源码包,里面包含了未编译的java文件。

  那么如何使用呢?

  

  首先在eclipse中添加外部的jar包,引入api.jar

  添加jar包,然后编辑sourceattachment,可以点击edit,也可以双击

  引入source文件,这样,我们就是查看api.jar包中的class文件的源码了!

  接下来进入正题,slf4j源码的解读!

  首先日志的用法很简单,通过工厂factory获取log对象,然后打印消息就可以了!看一下效果,无图无真相!

  main的代码在这里:

 1 package com.xingoo.test;
 2
 3 import java.util.Date;
 4
 5 import org.slf4j.Logger;
 6 import org.slf4j.LoggerFactory;
 7
 8 public class LogTest {
 9     public static void main(String[] args) {
10         Logger logger = LoggerFactory.getLogger(LogTest.class);
11         logger.info("hello {}",new Date());
12     }
13 }

  这里也可以看到Slf4j的一个很重要的特性,占位符!—— {} 可以任意的拼接字符串,自动的填入字符串中!用法用户可以自己去尝试,这里就不再赘述了。

  为了便于理解下面的代码,推荐先了解一下facade外观模式,因为Slf4j就是利用外观模式,提供对外的接口!

  可以参考之前整理的设计模式的帖子:设计模式

  首先,直接用LoggerFactory的静态工厂获取一个Logger对象,我们先看下getLogger方法!

1  public static Logger getLogger(Class clazz) {
2     return getLogger(clazz.getName());
3   }

  这里把传入的类,提取出名字,再填写到getLogger静态方法中!这里博友们可能有一个疑问,为什么要获取类的名字,而根据名字来获取对象呢。因为每个类使用的日志处理实现可能不同,iLoggerFactory中也是根据名字来判断一个类的实现方式的。

  public static Logger getLogger(String name) {
    ILoggerFactory iLoggerFactory = getILoggerFactory();
    return iLoggerFactory.getLogger(name);
  }

  在getLogger方法中,通过getLoggerFactory获取工厂,然后获取日志对象!看来一切的迷雾都在getILoggerFactory()中!

 1   public static ILoggerFactory getILoggerFactory() {
 2     if (INITIALIZATION_STATE == UNINITIALIZED) {
 3       INITIALIZATION_STATE = ONGOING_INITIALIZATION;
 4       performInitialization();
 5     }
 6     switch (INITIALIZATION_STATE) {
 7       case SUCCESSFUL_INITIALIZATION:
 8         return StaticLoggerBinder.getSingleton().getLoggerFactory();
 9       case NOP_FALLBACK_INITIALIZATION:
10         return NOP_FALLBACK_FACTORY;
11       case FAILED_INITIALIZATION:
12         throw new IllegalStateException(UNSUCCESSFUL_INIT_MSG);
13       case ONGOING_INITIALIZATION:
14         // support re-entrant behavior.
15         // See also http://bugzilla.slf4j.org/show_bug.cgi?id=106
16         return TEMP_FACTORY;
17     }
18     throw new IllegalStateException("Unreachable code");
19   }
20 }

  这个方法稍微复杂一点,总结起来:

  第2行~第5行:判断是否进行初始化,如果没有初始化,则修改状态,进入performIntialization初始化!

  第6行~第17行:对状态进行测试,如果初始化成功,则通过StaticLoggerBinder获取日志工厂!

  那么下面就看一下Slf4j如何进行初始化,又是如何获取日志工厂的!

  private final static void performInitialization() {
    bind();
    if (INITIALIZATION_STATE == SUCCESSFUL_INITIALIZATION) {
      versionSanityCheck();
    }
  }

  在初始化中,先bind(),在修改状态,进行版本检查!先看一下版本检查的内容:

  private final static void versionSanityCheck() {
    try {
      String requested = StaticLoggerBinder.REQUESTED_API_VERSION;

      boolean match = false;
      for (int i = 0; i < API_COMPATIBILITY_LIST.length; i++) {
        if (requested.startsWith(API_COMPATIBILITY_LIST[i])) {
          match = true;
        }
      }
      if (!match) {
        Util.report("The requested version " + requested
                + " by your slf4j binding is not compatible with "
                + Arrays.asList(API_COMPATIBILITY_LIST).toString());
        Util.report("See " + VERSION_MISMATCH + " for further details.");
      }
    } catch (java.lang.NoSuchFieldError nsfe) {
      // given our large user base and SLF4J‘s commitment to backward
      // compatibility, we cannot cry here. Only for implementations
      // which willingly declare a REQUESTED_API_VERSION field do we
      // emit compatibility warnings.
    } catch (Throwable e) {
      // we should never reach here
      Util.report("Unexpected problem occured during version sanity check", e);
    }
  }

  这里获取JDK的版本,并与Slf4j支持的版本进行比较,如果大版本相同则通过,如果不相同,那么进行失败提示!

  最关键的要看bind是如何实现的!

 1 private final static void bind() {
 2     try {
 3       Set<URL> staticLoggerBinderPathSet = findPossibleStaticLoggerBinderPathSet();
 4       reportMultipleBindingAmbiguity(staticLoggerBinderPathSet);
 5       // the next line does the binding
 6       StaticLoggerBinder.getSingleton();
 7       INITIALIZATION_STATE = SUCCESSFUL_INITIALIZATION;
 8       reportActualBinding(staticLoggerBinderPathSet);
 9       fixSubstitutedLoggers();
10     } catch (NoClassDefFoundError ncde) {
11       String msg = ncde.getMessage();
12       if (messageContainsOrgSlf4jImplStaticLoggerBinder(msg)) {
13         INITIALIZATION_STATE = NOP_FALLBACK_INITIALIZATION;
14         Util.report("Failed to load class \"org.slf4j.impl.StaticLoggerBinder\".");
15         Util.report("Defaulting to no-operation (NOP) logger implementation");
16         Util.report("See " + NO_STATICLOGGERBINDER_URL
17                 + " for further details.");
18       } else {
19         failedBinding(ncde);
20         throw ncde;
21       }
22     } catch (java.lang.NoSuchMethodError nsme) {
23       String msg = nsme.getMessage();
24       if (msg != null && msg.indexOf("org.slf4j.impl.StaticLoggerBinder.getSingleton()") != -1) {
25         INITIALIZATION_STATE = FAILED_INITIALIZATION;
26         Util.report("slf4j-api 1.6.x (or later) is incompatible with this binding.");
27         Util.report("Your binding is version 1.5.5 or earlier.");
28         Util.report("Upgrade your binding to version 1.6.x.");
29       }
30       throw nsme;
31     } catch (Exception e) {
32       failedBinding(e);
33       throw new IllegalStateException("Unexpected initialization failure", e);
34     }
35   }

  第2行~第10行:初始化!首先获取实现日志的加载路径,查看路径是否合法,再初始化StaticLoggerBinder的对象,寻找合适的实现方式使用。

  第10行~第22行:如果找不到指定的类,就会报错!

  第22行~第31行:如果找不到指定的方法,就会报错!

  第31行~第34行:报错!

  通关查看代码,可以理解,这个方法的主要功能就是寻找实现类,如果找不到或者指定的方法不存在,都会报错提示!

  那么如何查找实现类呢?这就要看findPossibleStaticLoggerBinderPathSet方法了!

 1 private static String STATIC_LOGGER_BINDER_PATH = "org/slf4j/impl/StaticLoggerBinder.class";
 2
 3   private static Set<URL> findPossibleStaticLoggerBinderPathSet() {
 4     // use Set instead of list in order to deal with  bug #138
 5     // LinkedHashSet appropriate here because it preserves insertion order during iteration
 6     Set<URL> staticLoggerBinderPathSet = new LinkedHashSet<URL>();
 7     try {
 8       ClassLoader loggerFactoryClassLoader = LoggerFactory.class
 9               .getClassLoader();
10       Enumeration<URL> paths;
11       if (loggerFactoryClassLoader == null) {
12         paths = ClassLoader.getSystemResources(STATIC_LOGGER_BINDER_PATH);
13       } else {
14         paths = loggerFactoryClassLoader
15                 .getResources(STATIC_LOGGER_BINDER_PATH);
16       }
17       while (paths.hasMoreElements()) {
18         URL path = (URL) paths.nextElement();
19         staticLoggerBinderPathSet.add(path);
20       }
21     } catch (IOException ioe) {
22       Util.report("Error getting resources from path", ioe);
23     }
24     return staticLoggerBinderPathSet;
25   }

  这里就是slf4j的源码精华之处!

  第1行:它定义了一个字符串,这个字符串是实现类的class地址。然后通过类加载加载指定的文件!

  第6行:创建一个Set,因为有可能有多个实现。

  第8行~第9行:获取LoggerFactory的类加载器!

  第11行~第13行:如果获取不到类加载器则说明是系统加载器,那么在系统路径下获取该资源文件

  第13行~第15行:获取到了类加载器,则用该类加载器加载指定的资源文件。

  第17行~第20行:解析类加载器的地址。

  第24行:返回加载器地址的集合。

  这里不了解类加载器的原理的可能会不大明白!

  在JVM中,最后的文件都是Class文件,也就是字节码文件,因此需要把该文件加载到JVM中才能运行。而加载的过程,只会执行静态代码块。

  类加载器分为三种:BootStrapClassLoader加载器,ExtensionClassLoader标准扩展加载器,SystemClassLoader系统类加载器。

  每一种加载器加载指定的class文件会得到不同的类,因此为了能够使用,这里必须要保证LoggerFactory的类加载器与StaticLoggerBinder的类加载是相同的。

  为了避免不同的加载器加载后会出现不一致的问题,JVM采用了一种父类委托机制的实现方式,也就是说,用户加载器会首先委托父类系统加载器,系统加载器再寻找父类——标准扩展加载器来加载类,而标准扩展加载器又会委托它的父类引导类加载器来加载,引导类加载器是属于最高级别的类加载器,它是没有父类加载器的。这里可以通过一个简单的图来表示他们的关系:

  而用户在运行期,也是获取不到引导类加载器的,因此当一个类获取它的类加载器,得到的对象时null,就说明它是由引导类加载器加载的。引导类加载器是负责加载系统目录下的文件,因此源码中使用getSystemresource来获取资源文件。

  这个地方虽然有点绕,但是理解起来还应该算简单吧!

  如果没有理解加载器的机制,那么推荐看一下《深入理解JVM》,或者推荐的帖子:类加载机制

  总结Slf4j工作原理

  上面的内容说多不多,说少也不少!

  你需要了解:JVM类加载机制、设计模式——外观模式,Eclipse jar包使用,然后就是慢慢的阅读源码。

  简单的说下它的原理,就是通过工厂类,提供一个用户的接口!用户可以通过这个外观接口,直接使用API实现日志的记录。而后面的具体实现由Slf4j来寻找加载.寻找的过程,就是通过类加载加载那个叫org/slf4j/impl/StaticLoggerBinder.class的文件,只要实现了这个文件的日志实现系统,都可以作为一种实现方式。如果找到很多种方式,那么就寻找一种默认的方式。

  这就是日志接口的工作方式,简单高效,关键是完全解耦!不需要日志实现部分提供任何的修改配置,只需要符合接口的标准就可以加载进来。

时间: 2024-11-06 15:26:50

日志那点事儿——slf4j源码剖析的相关文章

豆瓣Redis解决方案Codis源码剖析:Proxy代理

豆瓣Redis解决方案Codis源码剖析:Proxy代理 1.预备知识 1.1 Codis Codis就不详细说了,摘抄一下GitHub上的一些项目描述: Codis is a proxy based high performance Redis cluster solution written in Go/C, an alternative to Twemproxy. It supports multiple stateless proxy with multiple redis instan

菜鸟nginx源码剖析 框架篇(一) 从main函数看nginx启动流程(转)

俗话说的好,牵牛要牵牛鼻子 驾车顶牛,处理复杂的东西,只要抓住重点,才能理清脉络,不至于深陷其中,不能自拔.对复杂的nginx而言,main函数就是“牛之鼻”,只要能理清main函数,就一定能理解其中的奥秘,下面我们就一起来研究一下nginx的main函数. 1.nginx的main函数解读 nginx启动显然是由main函数驱动的,main函数在在core/nginx.c文件中,其源代码解析如下,涉及到的数据结构在本节仅指出其作用,将在第二节中详细解释. nginx main函数的流程图如下:

菜鸟nginx源码剖析数据结构篇(九) 内存池ngx_pool_t[转]

菜鸟nginx源码剖析数据结构篇(九) 内存池ngx_pool_t Author:Echo Chen(陈斌) Email:[email protected] Blog:Blog.csdn.net/chen19870707 Date:Nov 11th, 2014 今天是一年一度的光棍节,还没有女朋友的程序猿童鞋不妨new一个出来,内存管理一直是C/C++中最棘手的部分,远不止new/delete.malloc/free这么简单.随着代码量的递增,程序结构复杂度的提高.今天我们就一起研究一下以精巧著

【安卓笔记】HandlerThread源码剖析

有时候我们需要在应用程序中创建一些常驻的子线程不定期地执行一些计算型任务,这时候可以考虑使用HandlerThread,它具有创建带消息循环的子线程的作用. 一.HanderThread使用示例 先熟悉下HandlerThread的一般用法.我们创建一个如下所示的Activity: package com.example.handlethreaddemo; import android.app.Activity; import android.os.Bundle; import android.

【安卓笔记】IntentService源码剖析

Service组件想必都不陌生,这里不费口舌了.强调一点,Service组件默认运行在UI线程,所以也是会阻塞主线程的,使用时切记不可在Service中执行耗时操作,而应该创建子线程,异步执行. IntentService类封装了在Service中创建子线程的工作(其实创建的是HandlerThread),我们只需继承IntentService,复写其onHandleIntent方法即可,onHandleIntent方法在子线程中运行,该方法的参数Intent来自onStart或者onStart

Redis源码剖析和注释(十八)--- Redis AOF持久化机制

Redis AOF持久化机制 1. AOF持久化介绍 Redis中支持RDB和AOF这两种持久化机制,目的都是避免因进程退出,造成的数据丢失问题. RDB持久化:把当前进程数据生成时间点快照(point-in-time snapshot)保存到硬盘的过程,避免数据意外丢失. AOF持久化:以独立日志的方式记录每次写命令,重启时在重新执行AOF文件中的命令达到恢复数据的目的. Redis RDB持久化机制源码剖析和注释 AOF的使用:在redis.conf配置文件中,将appendonly设置为y

(升级版)Spark从入门到精通(Scala编程、案例实战、高级特性、Spark内核源码剖析、Hadoop高端)

本课程主要讲解目前大数据领域最热门.最火爆.最有前景的技术——Spark.在本课程中,会从浅入深,基于大量案例实战,深度剖析和讲解Spark,并且会包含完全从企业真实复杂业务需求中抽取出的案例实战.课程会涵盖Scala编程详解.Spark核心编程.Spark SQL和Spark Streaming.Spark内核以及源码剖析.性能调优.企业级案例实战等部分.完全从零起步,让学员可以一站式精通Spark企业级大数据开发,提升自己的职场竞争力,实现更好的升职或者跳槽,或者从j2ee等传统软件开发工程

Mongoose源码剖析:外篇之web服务器

转 http://www.cnblogs.com/skynet/archive/2010/07/24/1784110.html 这个博主里面很多关于mongoose的剖析 引言 在深入Mongoose源码剖析之前,我们应该清楚web服务器是什么?它提供什么服务?怎样提供服务?使用什么协议?客户端如何唯一标识web服务器的资源?下面我们抛开Mongoose,来介绍一个web服务的这些通性. web服务器:通常是指一个计算机程序(web服务器是什么?),在World Wide Web上提供诸如web

tomcat(11)org.apache.catalina.core.StandardWrapper源码剖析

[0]README 0.0)本文部分文字描述转自 "how tomcat works",旨在学习 "tomcat(11)StandardWrapper源码剖析" 的基础知识: 0.1)StandardWrapper 是 Catalina中对Wrapper接口的标准实现:要知道,tomcat 中有4种类型的容器:Engine,Host,Context 和 Wrapper:(干货--review  tomcat 中有4种类型的容器:Engine,Host,Context