Log4j2 JDBC Appender是否自动关闭连接？如何避免频繁启停连接？

你的推测是对的——Log4j2 JDBC Appender默认行为确实会在每次日志写入后关闭连接，频繁的连接建立/销毁是导致速度慢的核心原因。以下两种方案可以解决这个问题：

方案一：使用Log4j2内置连接池 #

Log4j2自带连接池支持，配置后Appender会复用连接池中的连接，无需每次重建。直接在配置文件中添加ConnectionPool节点即可：

<JDBC name="DatabaseAppender" tableName="error_logs">
  <!-- 配置内置连接池 -->
  <ConnectionPool driverClassName="com.mysql.cj.jdbc.Driver"
                  url="jdbc:mysql://your-db-host:3306/your-db"
                  userName="db-user"
                  password="db-pass"
                  maxPoolSize="15"  <!-- 最大连接数 -->
                  minIdle="3"       <!-- 最小空闲连接数 -->
                  connectionTimeout="5000"/> <!-- 连接超时时间 -->
  <!-- 日志字段映射 -->
  <Column name="log_level" pattern="%level"/>
  <Column name="log_content" pattern="%message"/>
  <Column name="log_time" pattern="%d{yyyy-MM-dd HH:mm:ss}" isEventTimestamp="true"/>
</JDBC>

这种方式无需额外代码，直接通过配置就能实现连接复用，是最简便的方案。

方案二：适配你的自定义连接类 #

如果你已经有自己的数据库连接管理类（程序终止前统一关闭连接），可以通过实现Log4j2的ConnectionSource接口，让Appender复用你已有的连接：

1. 实现ConnectionSource接口

import org.apache.logging.log4j.core.appender.db.ConnectionSource;
import java.sql.Connection;
import java.sql.SQLException;

public class CustomDBConnectionSource implements ConnectionSource {
    @Override
    public Connection getConnection() throws SQLException {
        // 返回自定义连接类中维护的共享连接
        return YourCustomDBManager.getPersistentConnection();
    }

    @Override
    public void shutdown() {
        // 留空即可——因为你会在程序终止时统一关闭连接
        // 若需要在这里触发关闭，也可以调用YourCustomDBManager.closeConnection()
    }
}

2. 在Log4j2配置中指定自定义连接源

<JDBC name="DatabaseAppender" tableName="error_logs">
  <!-- 指定自定义连接源类路径 -->
  <ConnectionSource class="com.your-package.CustomDBConnectionSource"/>
  <!-- 日志字段映射 -->
  <Column name="log_level" pattern="%level"/>
  <Column name="log_content" pattern="%message"/>
</JDBC>

这种方式完全复用你现有的连接管理逻辑，避免重复造轮子。

注意事项 #

• 若使用自定义连接源，必须确保你的共享连接是线程安全的——Log4j2的Appender可能在多线程环境下并发调用getConnection()。
• 无论哪种方案，都要做好连接泄漏防护：内置连接池会自动管理连接的回收，自定义连接类则需要确保连接不会因异常等情况意外关闭。

内容的提问来源于stack exchange，提问作者Will W.