logback源码解析之slf4j绑定实现解析

logback源码解析之slf4j绑定实现解析

已经工作4,5年了,经常使用各种日志框架,log4j,logback,logx,jul,jcl,log4j2等等,这些日至框架使用起来非常简单,易上手,但是自己实际上并没有对日志进行深入地分析和了解,

介于业界都评价logback日志系统做的精妙,基于学习的心理,来读读他的源码,预计花费一到两个月的时间,进行研究学习
那么读源码我们时,我们首先需要关注一下,他的入口

首先logback实现了slf4j,那么什么是slf4j呢?这里做一下简单的介绍,slf4j(simple logging facade for java) 他是一个简单的日志门面,并不是一个具体的日至解决方案,而logback就是他
的一个实现

logback版本:1.2.*
slf4j版本:1.7.25

其他版本的应该大同小异,但是slf4j1.8的去掉了用StaticLoggerBinder的方法

源码入口

说起logback的源码入口,咱们就需要从slf4j最关键的两个接口类说起,还有一个入口类,这3个类搞清楚,

首先最关键的两个接口,分别是Logger和ILoggerFactory. 最关键的入口类,是LoggerFactory

而所有具体实现框架,一定会实现Logger接口和ILoggerFactory接口,第一个实际记录日志,后者用来提供Logger,重要性不言自明.而LoggerFactory类,则是前面说过的入口类

 final static Logger logger = LoggerFactory.getLogger(MyApp1.class);

通过上面的代码,我们看出LoggerFactory.getLogger(),这个方法就是入口,那么咱们去看一下这个方法里到底都做了些什么

 public static Logger getLogger(Class<?> clazz) {
        Logger logger = getLogger(clazz.getName());
        if (DETECT_LOGGER_NAME_MISMATCH) {
            Class<?> autoComputedCallingClass = Util.getCallingClass();
            if (autoComputedCallingClass != null && nonMatchingClasses(clazz, autoComputedCallingClass)) {
                Util.report(String.format("Detected logger name mismatch. Given name: \"%s\"; computed name: \"%s\".", logger.getName(),
                                autoComputedCallingClass.getName()));
                Util.report("See " + LOGGER_NAME_MISMATCH_URL + " for an explanation");
            }
        }
        return logger;
    }

方法第一行调用了一个内部的getLogger()方法,那么这个方法里究竟做了什么呢?来让我们一步一步扒开伪装,看清他里面究竟是如何做的.上方法

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

这块代码中调用了另一个内部方法getLoggerFactory(),那么这个方法里面是做了什么呢,从方法名中看,这是一个工厂模式,工厂返回一个ILoggerFactory的实例,咱们接着往下看

    public static ILoggerFactory getILoggerFactory() {
        if (INITIALIZATION_STATE == UNINITIALIZED) {
            synchronized (LoggerFactory.class) {
                if (INITIALIZATION_STATE == UNINITIALIZED) {
                    INITIALIZATION_STATE = ONGOING_INITIALIZATION;
                    performInitialization();
                }
            }
        }
        switch (INITIALIZATION_STATE) {
        case SUCCESSFUL_INITIALIZATION:
            return StaticLoggerBinder.getSingleton().getLoggerFactory();
        case NOP_FALLBACK_INITIALIZATION:
            return NOP_FALLBACK_FACTORY;
        case FAILED_INITIALIZATION:
            throw new IllegalStateException(UNSUCCESSFUL_INIT_MSG);
        case ONGOING_INITIALIZATION:
            // support re-entrant behavior.
            // See also http://jira.qos.ch/browse/SLF4J-97
            return SUBST_FACTORY;
        }
        throw new IllegalStateException("Unreachable code");
    }

这段代码,第一部分检查初始化状态,如果是未初始化的情况,会有一个同步对象的方法,来处理初始化,
第二部分的代码就是处理不同状态返回值,如正常初始化成功,NOP初始化,初始化失败,正在初始化,其他状态都为失败

咱们先看一下未初始化这部分代码,首先这里用了double check, 未同步LoggerFactory对象时,判断一次初始化状态,同步后,判断一次状态,如果还是位初始化,则首先把初始化状态改为正在初始化状态,接下来就是关键的初始化代码了performInitialization(), 开始真正的执行初始化方法,咱们先来看看他初始化代码中都做了什么

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

这是一个方法用final修改是无法修改的,这个方法里很简单一个bind()方法,第二部对初始化成功后做的版本检查

那么咱们就先来看看bind()方法内部究竟是在做了什么

    private final static void bind() {
        try {
            Set<URL> staticLoggerBinderPathSet = null;
            // skip check under android, see also
            // http://jira.qos.ch/browse/SLF4J-328
            if (!isAndroid()) {
                staticLoggerBinderPathSet = findPossibleStaticLoggerBinderPathSet();
                reportMultipleBindingAmbiguity(staticLoggerBinderPathSet);
            }
            // the next line does the binding
            StaticLoggerBinder.getSingleton();
            INITIALIZATION_STATE = SUCCESSFUL_INITIALIZATION;
            reportActualBinding(staticLoggerBinderPathSet);
            fixSubstituteLoggers();
            replayEvents();
            // release all resources in SUBST_FACTORY
            SUBST_FACTORY.clear();
        } catch (NoClassDefFoundError ncde) {
            String msg = ncde.getMessage();
            if (messageContainsOrgSlf4jImplStaticLoggerBinder(msg)) {
                INITIALIZATION_STATE = NOP_FALLBACK_INITIALIZATION;
                Util.report("Failed to load class \"org.slf4j.impl.StaticLoggerBinder\".");
                Util.report("Defaulting to no-operation (NOP) logger implementation");
                Util.report("See " + NO_STATICLOGGERBINDER_URL + " for further details.");
            } else {
                failedBinding(ncde);
                throw ncde;
            }
        } catch (java.lang.NoSuchMethodError nsme) {
            String msg = nsme.getMessage();
            if (msg != null && msg.contains("org.slf4j.impl.StaticLoggerBinder.getSingleton()")) {
                INITIALIZATION_STATE = FAILED_INITIALIZATION;
                Util.report("slf4j-api 1.6.x (or later) is incompatible with this binding.");
                Util.report("Your binding is version 1.5.5 or earlier.");
                Util.report("Upgrade your binding to version 1.6.x.");
            }
            throw nsme;
        } catch (Exception e) {
            failedBinding(e);
            throw new IllegalStateException("Unexpected initialization failure", e);
        }
    }

代码分两部分 ,第一部分首先定义了一个静态绑定的集合,然后判断如果不是安卓的话,需要查找可能会有集合路径,然后报告可能存在多个绑定,但是多个绑定,

首先来看看slf4j是如何查找类路径下是由多个绑定的findPossibleStaticLoggerBinderPathSet这个方法
方法内容如下

    static Set<URL> findPossibleStaticLoggerBinderPathSet() {
        // use Set instead of list in order to deal with bug #138
        // LinkedHashSet appropriate here because it preserves insertion order
        // during iteration
        Set<URL> staticLoggerBinderPathSet = new LinkedHashSet<URL>();
        try {
            ClassLoader loggerFactoryClassLoader = LoggerFactory.class.getClassLoader();
            Enumeration<URL> paths;
            if (loggerFactoryClassLoader == null) {
                paths = ClassLoader.getSystemResources(STATIC_LOGGER_BINDER_PATH);
            } else {
                paths = loggerFactoryClassLoader.getResources(STATIC_LOGGER_BINDER_PATH);
            }
            while (paths.hasMoreElements()) {
                URL path = paths.nextElement();
                staticLoggerBinderPathSet.add(path);
            }
        } catch (IOException ioe) {
            Util.report("Error getting resources from path", ioe);
        }
        return staticLoggerBinderPathSet;
    }

首先这里用了另一个LinkedHashSet集合,为什么呢?我是这么想的,如果这里用了HashSet之类的,那么假如有多个Slf4j绑定实现在处理时,取第一个时候,就有可能不是按放入的顺序来处理了,OK,接下来这里获取加载LoggerFactory的ClassLoader,那么获取这个类加载去做什么呢?,下面的代码也很简单,直接判断获取loggerFactoryClassLoader是否为空,如果为空的话,用系统类加载器获取STATIC_LOGGER_BINDER_PATH ,通过查看定义发现STATIC_LOGGER_BINDER_PATH的值为”org/slf4j/impl/StaticLoggerBinder.class”, 那么getSystemResources是用来做什么的或者getResources, OK ,这个方法差不多看完了,就是把返回的多个类的绝对路径返回,那么咱们再往底层看,看getResources下面是怎么处理,怎么查找出类在那个jar包中,代码如下

ClassLoader.getResource(path) 从/下查找，path以/开头会返回null,会缓存结果
ClassLoader.getResources(path) 同上,返回多个
ClassLoader.getSystemResource(path) 不会缓存结果,每次都会重新加载

    public Enumeration<URL> getResources(String name) throws IOException {
        @SuppressWarnings("unchecked")
        Enumeration<URL>[] tmp = (Enumeration<URL>[]) new Enumeration<?>[2];
        if (parent != null) {
            tmp[0] = parent.getResources(name);
        } else {
            tmp[0] = getBootstrapResources(name);
        }
        tmp[1] = findResources(name);

        return new CompoundEnumeration<>(tmp);
    }

首先判断该类加载器是否有父加载器,如果有的话,就让父加载器处理,如果没有调用getBootstrapResources,

由于父类的类加载器还是该方法,那么我们直接来看getBootstrapResources()这个方法

    private static Enumeration<URL> getBootstrapResources(String name)
        throws IOException
    {
        final Enumeration<Resource> e =
            getBootstrapClassPath().getResources(name);
        return new Enumeration<URL> () {
            public URL nextElement() {
                return e.nextElement().getURL();
            }
            public boolean hasMoreElements() {
                return e.hasMoreElements();
            }
        };
    }

这个方法中就是获取getBootstrapClassPath()

我们来查看一下这个方法的实现

static URLClassPath getBootstrapClassPath() {
        return sun.misc.Launcher.getBootstrapClassPath();
    }

Ok,到这里,如果再往下面看就是Java的入口类,那么入口类实际上使用C写的,下面的代码就需要深入JVM源码,才能看到了,咱们只是为了一探slf4j那么我们就接着前面的内容,ClassLoader的内容就到此结束了,findPossibleStaticLoggerBinderPathSet,接着我们查找到的绑定实现类后,需要报告,那么看一下什么情况下会报多个绑定存在reportMultipleBindingAmbiguity()

    private static void reportMultipleBindingAmbiguity(Set<URL> binderPathSet) {
        if (isAmbiguousStaticLoggerBinderPathSet(binderPathSet)) {
            Util.report("Class path contains multiple SLF4J bindings.");
            for (URL path : binderPathSet) {
                Util.report("Found binding in [" + path + "]");
            }
            Util.report("See " + MULTIPLE_BINDINGS_URL + " for an explanation.");
        }
    }

首先判断是否存在多个绑定在类路径中,那么咱们看一下这个是如何判断的,这个判断也非常简单,只要集合的数量大于1即说明类路径下面存在多个slf4j的绑定实现

org.slf4j.LoggerFactory

    private static boolean isAmbiguousStaticLoggerBinderPathSet(Set<URL> binderPathSet) {
        return binderPathSet.size() > 1;
    }

如果是大于1,那么会打印一条警告信息,Util.report(),那么这个警告信息是如何处理的,咱们看一下这个静态的工具类

org.slf4j.helpers.Util

    static final public void report(String msg) {
        System.err.println("SLF4J: " + msg);
    }

Utils.report方法很简单,是静态方法,方法内部调用的是System.err.这个都是一目了然的,不解释

OK,到这里,slf4j,会把类路径下面可能有多个绑定通过ClassLoader,加载出来,然后如果有多个会警告,那么静下来需要做什么呢?咱们接着看bind()方法,接下来就是关键代码StaticLoggerBinder.getSingleton();

下面就是logback的具体实现了,由于篇幅太大,分来两篇来写,接下来写logback是如何初始化,配置文件是如何处理的