首页 星云 工具 资源 星选 资讯 热门工具
:

PDF转图片 完全免费 小红书视频下载 无水印 抖音视频下载 无水印 数字星空

从源码分析 SpringBoot 的 LoggingSystem → 它是如何绑定日志组件的

编程知识
2024年08月22日 07:39

开心一刻

今天心情不好，想约哥们喝点

我：心情不好，给你女朋友说一声，来我家，过来喝点

哥们：行！我给她说一声

我：你想吃啥？我点外卖

哥们：你俩定吧，我已经让她过去了

我：？？？我踏马让你过来！和她说一声

哥们：哈哈哈，我踏马寻思让她过去呢

成功给我逗笑了

前情回顾

SpringBoot2.7 霸王硬上弓 Logback1.3 → 不甜但解渴 实现了 spring-boot 2.x.x 与 logback 1.3.x 的集成，分两步

  1. 关闭 Spring Boot 的 LoggingSystem
  2. 配置文件用 logback.xml

从示例看，集成是成功的；但有些问题是没有分析的，比如

  1. System.setProperty("org.springframework.boot.logging.LoggingSystem", "none") 是如何生效的
  2. Spring Boot 的 LoggingSystem 是如何与日志组件绑定的
  3. Spring Boot 默认依赖 3 个日志组件：logback、log4j、jul，为什么默认启用的是 logback，而非其它两个？

基于如上 3 个问题，我们一起去翻一翻 Spring Boot 的源码；在看源码之前，我先带大家回顾一些内容，方便下文的源码分析

  1. 设计模式之观察者模式 → 事件机制的底层原理

    讲了观察者模式的实现，以及在 JDK 中的应用（JDK 事件模型）、Spring 中的应用（事件机制）；大家可以重点看下 Spring 的那个案例，使用非常简单，总结一句就是

    SpringBoot 启动过程中发送的事件，所有 ApplicationListener 都会收到（即 onApplicationEvent 方法会被调用）

  2. spring-boot-2.0.3启动源码篇一 - SpringApplication构造方法

    大家不要通篇去读，重点看 getSpringFactoriesInstances，与本文息息相关的归纳成一句

    查找类路径下全部的 META-INF/spring.factories 的文件路径，并加载所有 spring.factories 中的内容到 SpringFactoriesLoader 的 cache 中，然后从缓存中获取 ApplicationListener 类型的类并进行实例化

下文是基于 Spring Boot 默认情况下的源码分析，而非集成 logback 1.3.x 的源码分析，大家注意下

集成 logback 1.3.x 需要关闭 Spring Boot 的 LoggingSystem，那还分析个毛

源码分析

问题来了，从哪开始跟？我就不绕圈子了，从 LoggingApplicationListener 开始跟，首先它在 META-INF/spring.factories 中

spring.factories_LoggingApplicationListener

其次它实现了 ApplicationListener

LoggingApplicationListener类图

那么 Spring Boot 在启动过程中会实例化 LoggingApplicationListener，Spring Boot 启动过程中发送的事件都会来到 LoggingApplicationListener 的 onApplicationEvent 方法

@Override
public void onApplicationEvent(ApplicationEvent event) {
	if (event instanceof ApplicationStartingEvent) {
		onApplicationStartingEvent((ApplicationStartingEvent) event);
	}
	else if (event instanceof ApplicationEnvironmentPreparedEvent) {
		onApplicationEnvironmentPreparedEvent((ApplicationEnvironmentPreparedEvent) event);
	}
	else if (event instanceof ApplicationPreparedEvent) {
		onApplicationPreparedEvent((ApplicationPreparedEvent) event);
	}
	else if (event instanceof ContextClosedEvent) {
		onContextClosedEvent((ContextClosedEvent) event);
	}
	else if (event instanceof ApplicationFailedEvent) {
		onApplicationFailedEvent();
	}
}

Spring Boot 启动过程分不同的阶段，在每个阶段都会发送对应阶段的事件，LoggingApplicationListener 针对这些事件会有不同的处理，我们暂且只需要关注以下事件

ApplicationStartingEvent，对应的处理方法：onApplicationStartingEvent

ApplicationEnvironmentPreparedEvent，对应的处理方法：onApplicationEnvironmentPreparedEvent

ApplicationPreparedEvent，对应的处理方法：onApplicationPreparedEvent

onApplicationStartingEvent

private void onApplicationStartingEvent(ApplicationStartingEvent event) {
	this.loggingSystem = LoggingSystem.get(event.getSpringApplication().getClassLoader());
	this.loggingSystem.beforeInitialize();
}

方法很简单，获取日志系统，然后调用其 beforeInitialize 方法，我们跟进 LoggingSystem.get

public static LoggingSystem get(ClassLoader classLoader) {
	String loggingSystemClassName = System.getProperty(SYSTEM_PROPERTY);
	if (StringUtils.hasLength(loggingSystemClassName)) {
		if (NONE.equals(loggingSystemClassName)) {
			return new NoOpLoggingSystem();
		}
		return get(classLoader, loggingSystemClassName);
	}
	LoggingSystem loggingSystem = SYSTEM_FACTORY.getLoggingSystem(classLoader);
	Assert.state(loggingSystem != null, "No suitable logging system located");
	return loggingSystem;
}

打个断点调试下，你们就会发现 SYSTEM_PROPERTY 的值是 org.springframework.boot.logging.LoggingSystem

system_property

从系统属性中获取 org.springframework.boot.logging.LoggingSystem ，是不是和

System.setProperty("org.springframework.boot.logging.LoggingSystem", "none") 是如何生效的

对应上了？如果获取的值是 none，直接返回 NoOpLoggingSystem 实例

/**
 * {@link LoggingSystem} that does nothing.
 */
static class NoOpLoggingSystem extends LoggingSystem {

	@Override
	public void beforeInitialize() {

	}

	@Override
	public void setLogLevel(String loggerName, LogLevel level) {

	}

	@Override
	public List<LoggerConfiguration> getLoggerConfigurations() {
		return Collections.emptyList();
	}

	@Override
	public LoggerConfiguration getLoggerConfiguration(String loggerName) {
		return null;
	}

}

全是空实现，相当于关闭了 Spring Boot 的 LoggingSystem；org.springframework.boot.logging.LoggingSystem 还可以设置成其他值，但需要有对应的实现。默认情况下 loggingSystemClassName 的值是 null ，会跳过 if 来到 SYSTEM_FACTORY.getLoggingSystem(classLoader);

@Override
public LoggingSystem getLoggingSystem(ClassLoader classLoader) {
	List<LoggingSystemFactory> delegates = (this.delegates != null) ? this.delegates.apply(classLoader) : null;
	if (delegates != null) {
		for (LoggingSystemFactory delegate : delegates) {
			LoggingSystem loggingSystem = delegate.getLoggingSystem(classLoader);
			if (loggingSystem != null) {
				return loggingSystem;
			}
		}
	}
	return null;
}

这里推荐用断点调试去跟源码，按 F7 之后会来到 LoggingSystemFactory#fromSpringFactories

/**
 * Return a {@link LoggingSystemFactory} backed by {@code spring.factories}.
 * @return a {@link LoggingSystemFactory} instance
 */
static LoggingSystemFactory fromSpringFactories() {
	return new DelegatingLoggingSystemFactory(
			(classLoader) -> SpringFactoriesLoader.loadFactories(LoggingSystemFactory.class, classLoader));
}

SpringFactoriesLoader.loadFactories 是不是很眼熟？（不眼熟的去看：spring-boot-2.0.3启动源码篇一 - SpringApplication构造方法）此时它会做三件事

  1. 从 SpringFactoriesLoader#cache 中获取 LoggingSystemFactory 类型的工厂类的类名列表

    spring.factories_LoggingSystemFactory

    之前已经加载到 SpringFactoriesLoader#cache 中，所以此时从缓存中获取；注意看三个实现类的顺序，LogbackLoggingSystem.Factory 在最前面

  2. 实例化这些工厂类

  3. 对这些工厂类实例按 @Order 升序排序

    这三个工厂类的 @Order 值是一样的，都是 @Order(Ordered.LOWEST_PRECEDENCE)，所以顺序不变，LogbackLoggingSystem.Factory 仍在最前面

    LoggingSystemFactory列表

回到 DelegatingLoggingSystemFactory#getLoggingSystem，对这些工厂类实例逐个遍历，得到 LoggingSystem 立即返回，不再遍历后面的工厂实例；第一个遍历的的是 LogbackLoggingSystem.Factory，调用其 getLoggingSystem 方法

private static final boolean PRESENT = ClassUtils.isPresent("ch.qos.logback.classic.LoggerContext",
		Factory.class.getClassLoader());

@Override
public LoggingSystem getLoggingSystem(ClassLoader classLoader) {
	if (PRESENT) {
		return new LogbackLoggingSystem(classLoader);
	}
	return null;
}

ch.qos.logback.classic.LoggerContext 存在（即存在logback依赖），直接创建 LogbackLoggingSystem 实例并返回；至此 Spring Boot 的 LoggingSystem 确定将基于 logback，而非 log4j，也非 jul，问题

Spring Boot 的 LoggingSystem 是如何与日志组件绑定的

Spring Boot 默认依赖 3 个日志组件：logback、log4j、jul，为什么默认启用的是 logback，而非其它两个？

是不是清楚了？LoggingSystem 确定为 LogbackLoggingSystem 后回到 LoggingApplicationListener#onApplicationStartingEvent 方法的第二行，即调用 LogbackLoggingSystem#beforeInitialize 方法

@Override
public void beforeInitialize() {
	LoggerContext loggerContext = getLoggerContext();
	if (isAlreadyInitialized(loggerContext)) {
		return;
	}
	super.beforeInitialize();
	loggerContext.getTurboFilterList().add(FILTER);
}

主要初始化 LoggerContext，跟进 getLoggerContext()

private LoggerContext getLoggerContext() {
	ILoggerFactory factory = StaticLoggerBinder.getSingleton().getLoggerFactory();
	Assert.isInstanceOf(LoggerContext.class, factory,
			() -> String.format(
					"LoggerFactory is not a Logback LoggerContext but Logback is on "
							+ "the classpath. Either remove Logback or the competing "
							+ "implementation (%s loaded from %s). If you are using "
							+ "WebLogic you will need to add 'org.slf4j' to "
							+ "prefer-application-packages in WEB-INF/weblogic.xml",
					factory.getClass(), getLocation(factory)));
	return (LoggerContext) factory;
}

StaticLoggerBinder 有没有很熟悉？看下它的全类名：org.slf4j.impl.StaticLoggerBinder，在 logback-classic-1.2.12.jar 下 ，而 logback 1.3.x 没有这个类

所以 spring-boot 2.x.x 默认不支持 logback 1.3.x

总结下，onApplicationStartingEvent 方法确定了日志系统是 LogbackLoggingSystem

onApplicationEnvironmentPreparedEvent

private void onApplicationEnvironmentPreparedEvent(ApplicationEnvironmentPreparedEvent event) {
	SpringApplication springApplication = event.getSpringApplication();
	if (this.loggingSystem == null) {
		this.loggingSystem = LoggingSystem.get(springApplication.getClassLoader());
	}
	initialize(event.getEnvironment(), springApplication.getClassLoader());
}

很显然 loggingSystem 不为 null，我们直接跟 initialize 方法

protected void initialize(ConfigurableEnvironment environment, ClassLoader classLoader) {
	getLoggingSystemProperties(environment).apply();
	this.logFile = LogFile.get(environment);
	if (this.logFile != null) {
		this.logFile.applyToSystemProperties();
	}
	// 日志分组，暂不关注
	this.loggerGroups = new LoggerGroups(DEFAULT_GROUP_LOGGERS);
	// 设置早期日志级别，主要debug和trace之间的抉择
	initializeEarlyLoggingLevel(environment);
	// 初始化日志系统
	initializeSystem(environment, this.loggingSystem, this.logFile);
	// 设置最终日志级别
	initializeFinalLoggingLevels(environment, this.loggingSystem);
	registerShutdownHookIfNecessary(environment, this.loggingSystem);
}

我们暂时只关注 initializeSystem 方法

initializeSystempng

继续往下跟，来到 LogbackLoggingSystem#initialize

LogbackLoggingSystem

继续往下跟，来到 AbstractLoggingSystem#initialize

AbstractLoggingSystem

继续往下跟，来到 AbstractLoggingSystem#initializeWithConventions

private void initializeWithConventions(LoggingInitializationContext initializationContext, LogFile logFile) {
	String config = getSelfInitializationConfig();
	if (config != null && logFile == null) {
		// self initialization has occurred, reinitialize in case of property changes
		reinitialize(initializationContext);
		return;
	}
	if (config == null) {
		config = getSpringInitializationConfig();
	}
	if (config != null) {
		loadConfiguration(initializationContext, config, logFile);
		return;
	}
	loadDefaults(initializationContext, logFile);
}

其中 getSelfInitializationConfig() 就是从 classpath 下逐个寻找

logback-test.groovy, logback-test.xml, logback.groovy, logback.xml

这四个文件，一旦找到则直接返回；因为找到了 logback.xml，所以来到第一个 if

initializeWithConventions-reinitialize

继续跟进，来到 LogbackLoggingSystem#reinitialize

LogbackLoggingSystem

将logback.xml 中的配置进行加载；至此，Spring Boot 的 LoggingSystem 与 Logback 的绑定就完成了，你们清楚了吗？

我们重新回到 AbstractLoggingSystem#initializeWithConventions ，如果 classpath 下

logback-test.groovy, logback-test.xml, logback.groovy, logback.xml

这四个文件都没有，会来到 config = getSpringInitializationConfig();，逐步跟下去会来到 AbstractLoggingSystem#getSpringConfigLocations

protected String[] getSpringConfigLocations() {
	String[] locations = getStandardConfigLocations();
	for (int i = 0; i < locations.length; i++) {
		String extension = StringUtils.getFilenameExtension(locations[i]);
		locations[i] = locations[i].substring(0, locations[i].length() - extension.length() - 1) + "-spring."
				+ extension;
	}
	return locations;
}

这个方法大家都能看懂吧，locations 的值

logback-test.groovy, logback-test.xml, logback.groovy, logback.xml

逐个遍历，然后进行拼接，最终得到

logback-test-spring.groovy, logback-test-spring.xml, logback-spring.groovy, logback-spring.xml

getSpringConfigLocations

同样从 classpath 下逐个寻找，一旦找到直接返回；这也是为什么我们的日志配置文件是 logback-spring.xml 也能生效的原因。我们可以给 Spring Boot 的日志配置文件排个优先级

logback-test.groovy > logback-test.xml > logback.groovy > logback.xml > logback-test-spring.groovy > logback-test-spring.xml > logback-spring.groovy > logback-spring.xml

总结下，onApplicationEnvironmentPreparedEvent 完成了日志系统的初始化（日志配置文件的加载）

onApplicationPreparedEvent

private void onApplicationPreparedEvent(ApplicationPreparedEvent event) {
	ConfigurableApplicationContext applicationContext = event.getApplicationContext();
	ConfigurableListableBeanFactory beanFactory = applicationContext.getBeanFactory();
	if (!beanFactory.containsBean(LOGGING_SYSTEM_BEAN_NAME)) {
		beanFactory.registerSingleton(LOGGING_SYSTEM_BEAN_NAME, this.loggingSystem);
	}
	if (this.logFile != null && !beanFactory.containsBean(LOG_FILE_BEAN_NAME)) {
		beanFactory.registerSingleton(LOG_FILE_BEAN_NAME, this.logFile);
	}
	if (this.loggerGroups != null && !beanFactory.containsBean(LOGGER_GROUPS_BEAN_NAME)) {
		beanFactory.registerSingleton(LOGGER_GROUPS_BEAN_NAME, this.loggerGroups);
	}
	if (!beanFactory.containsBean(LOGGING_LIFECYCLE_BEAN_NAME) && applicationContext.getParent() == null) {
		beanFactory.registerSingleton(LOGGING_LIFECYCLE_BEAN_NAME, new Lifecycle());
	}
}

代码不复杂，就是注册了几个 Bean 到 Spring 容器，其中的 loggingSystem 是我们暂时比较关注的，默认情况下其类型是：LogbackLoggingSystem

日志打印

Spring Boot 的 LoggingSystem 完成与 Logback 的绑定后，它是如何使用然后打印日志的呢？是不是也像

业务日志打印样例

这样来使用的？那绝对不可能的！

绝对不可能

这么使用的话，跟 Spring Boot 的 LoggingSystem 有鸡毛的关系？我们来看下 Spring Boot 中日志的使用，SpringApplication 179 行就用到了

SpringApplicaton179行

我们会发现 Log、LogFactory 在 spring-jcl-5.3.31.jar 包下

spring-jcl_LogFactory

spring-jcl 类似 slf4j，也是一个日志门面，本文不展开

跟进 LogFactory.getLog ，一路跟下去会来到 LogAdapter#createLog

public static Log createLog(String name) {
	switch (logApi) {
		case LOG4J:
			return Log4jAdapter.createLog(name);
		case SLF4J_LAL:
			return Slf4jAdapter.createLocationAwareLog(name);
		case SLF4J:
			return Slf4jAdapter.createLog(name);
		default:
			// Defensively use lazy-initializing adapter class here as well since the
			// java.logging module is not present by default on JDK 9. We are requiring
			// its presence if neither Log4j nor SLF4J is available; however, in the
			// case of Log4j or SLF4J, we are trying to prevent early initialization
			// of the JavaUtilLog adapter - e.g. by a JVM in debug mode - when eagerly
			// trying to parse the bytecode for all the cases of this switch clause.
			return JavaUtilAdapter.createLog(name);
	}
}

logApi 的值获取如下

private static final String LOG4J_SPI = "org.apache.logging.log4j.spi.ExtendedLogger";

private static final String LOG4J_SLF4J_PROVIDER = "org.apache.logging.slf4j.SLF4JProvider";

private static final String SLF4J_SPI = "org.slf4j.spi.LocationAwareLogger";

private static final String SLF4J_API = "org.slf4j.Logger";

private static final LogApi logApi;

static {
	if (isPresent(LOG4J_SPI)) {
		if (isPresent(LOG4J_SLF4J_PROVIDER) && isPresent(SLF4J_SPI)) {
			// log4j-to-slf4j bridge -> we'll rather go with the SLF4J SPI;
			// however, we still prefer Log4j over the plain SLF4J API since
			// the latter does not have location awareness support.
			logApi = LogApi.SLF4J_LAL;
		}
		else {
			// Use Log4j 2.x directly, including location awareness support
			logApi = LogApi.LOG4J;
		}
	}
	else if (isPresent(SLF4J_SPI)) {
		// Full SLF4J SPI including location awareness support
		logApi = LogApi.SLF4J_LAL;
	}
	else if (isPresent(SLF4J_API)) {
		// Minimal SLF4J API without location awareness support
		logApi = LogApi.SLF4J;
	}
	else {
		// java.util.logging as default
		logApi = LogApi.JUL;
	}
}

根据优先级逐个去类路径下寻找类，找到了直接返回；Spring Boot 默认情况下用的是 SLF4J + Logback，所以 logApi 的值是 SLF4J_SPI，那么 LogAdapter#createLog 的返回值的类型是 LogAdapter$Slf4jLocationAwareLog

LogAdapter$Slf4jLocationAwareLog

相当于完成了 spring-jcl 到 slf4j 的适配；这么说来，Spring Boot 日志还是走的 SLF4J + Logback ？跟 Spring Boot 的 LoggingSystem 有什么关系呢？敬请期待下篇

未完待续

总结

  1. onApplicationStartingEvent

    确定日志系统类型并创建对应的 LoggingSystem，默认情况下是 LogbackLoggingSystem

  2. onApplicationEnvironmentPreparedEvent

    完成日志配置文件的加载以及 LoggingSystem 的初始化

  3. Spring Boot 的日志打印貌似与 LoggingSystem 没有关系？下篇分析

From:https://www.cnblogs.com/youzhibing/p/18362863
本文地址: http://shuzixingkong.net/article/1317
0评论
提交 加载更多评论
其他文章 DDD建模后写代码的正确姿势（Java、dotnet双平台）
本文书接上回《一种很变态但有效的DDD建模沟通方式》，关注公众号（老肖想当外语大佬）获取信息： 最新文章更新； DDD框架源码（.NET、Java双平台）； 加群畅聊，建模分析、技术交流； 视频和直播在B站。 终于到了写代码的环节 如果你已经阅读过本系列前面的所有文章，我相信你对需求分析和建模设计有
DDD建模后写代码的正确姿势（Java、dotnet双平台） DDD建模后写代码的正确姿势（Java、dotnet双平台） DDD建模后写代码的正确姿势（Java、dotnet双平台）
使用分布式锁解决IM聊天数据重复插入的问题
导航 业务背景 问题分析与定位 探索可行的解决方案 数据库层面处理——唯一索引 应用程序层面处理——分布式锁 分布式锁概述 分布式锁需要具备哪些特性？ 分布式锁有哪些实现方式？ 基于数据库的实现方式 基于Redisson实现方式 Redission介绍 概述 可重入锁 基于Redisson解决方案
使用分布式锁解决IM聊天数据重复插入的问题 使用分布式锁解决IM聊天数据重复插入的问题 使用分布式锁解决IM聊天数据重复插入的问题
Dapr v1.14 版本已发布
Dapr是一套开源、可移植的事件驱动型运行时，允许开发人员轻松立足云端与边缘位置运行弹性、微服务、无状态以及有状态等应用程序类型。Dapr能够确保开发人员专注于编写业务逻辑，而不必分神于解决分布式系统难题，由此显著提高生产力并缩短开发时长。Dapr 是用于构建云原生应用程序的开发人员框架，可以更轻松
 使用FModel提取黑神话悟空的资产
目录前言设置效果展示闲聊可能遇到的问题没有相应的UE引擎版本选项 前言 黑神话悟空昨天上线了，解个包looklook。 本文内容比较简洁，仅介绍解包黑神话所需的专项配置，关于FModel的基础使用流程，请见《使用FModel提取UE4/5游戏资产》 本文仅演示steam平台下的解包过程 设置 在FM
使用FModel提取黑神话悟空的资产 使用FModel提取黑神话悟空的资产 使用FModel提取黑神话悟空的资产
一个能够生成 Markdown 表格的 Bash 脚本
哈喽大家好，我是咸鱼。 今天分享一个很实用的 bash 脚本，可以通过手动提供单元格内容和列数或者将带有分隔符的文件（如 CSV、TSV 文件）转换为 Markdown 表格。 源代码在文末哦！原文链接：https://josh.fail/2022/pure-bash-markdown-table-
 聊聊 PHP 多进程模式下的孤儿进程和僵尸进程
在 PHP 的编程实践中多进程通常都是在 cli 脚本的模式下使用，我依稀还记得在多年以前为了实现从数据库导出千万级别的数据，第一次在 PHP 脚本中采用了多进程编程。
聊聊 PHP 多进程模式下的孤儿进程和僵尸进程 聊聊 PHP 多进程模式下的孤儿进程和僵尸进程
零基础学习人工智能—Python—Pytorch学习（七）
前言 本文主要讲神经网络的下半部分。 其实就是结合之前学习的全部内容，进行一次神经网络的训练。 神经网络 下面是使用MNIST数据集进行的手写数字识别的神经网络训练和使用。 MNIST 数据集，是一个常用的手写数字识别数据集。MNIST 数据集包含 60,000 张 28x28 像素的灰度训练图像和
零基础学习人工智能—Python—Pytorch学习（七） 零基础学习人工智能—Python—Pytorch学习（七） 零基础学习人工智能—Python—Pytorch学习（七）
SLAB：华为开源，通过线性注意力和PRepBN提升Transformer效率 | ICML 2024
论文提出了包括渐进重参数化批归一化和简化线性注意力在内的新策略，以获取高效的Transformer架构。在训练过程中逐步将LayerNorm替换为重参数化批归一化，以实现无损准确率，同时在推理阶段利用BatchNorm的高效优势。此外，论文设计了一种简化的线性注意力机制，其在计算成本较低的情况下达到
SLAB：华为开源，通过线性注意力和PRepBN提升Transformer效率 | ICML 2024 SLAB：华为开源，通过线性注意力和PRepBN提升Transformer效率 | ICML 2024 SLAB：华为开源，通过线性注意力和PRepBN提升Transformer效率 | ICML 2024
本站由星云主机提供云计算服务

网站建设一条龙服务、小程序开发、企业网站建设、定制开发，网络安全检测与维护 业务合作联系QQ:九六九五七三七