应用运行数小时后出现commons-pool2实例创建失败问题求助

从你提供的错误堆栈和代码来看，核心问题是运行一段时间后，连接池在尝试初始化DefaultEvictionPolicy时触发了ClassNotFoundException。这个错误不是启动时出现，而是1-2小时后才触发，说明不是简单的依赖缺失，而是和类加载器上下文、异步线程环境或连接池运行时行为有关。下面分点拆解原因并给出针对性解决方案：

1. 异步线程的类加载器上下文不一致 #

你用CompletableFuture.supplyAsync()默认会使用JDK的ForkJoinPool，这个线程池的类加载器可能和你的Web应用类加载器（比如Tomcat的WebAppClassLoader）不一致。当连接池在异步线程中尝试加载DefaultEvictionPolicy时，找不到对应的类。

解决方案： #

• 使用应用上下文的线程池：不要用默认的ForkJoinPool，而是传入Spring容器管理的线程池，确保线程的类加载器和应用一致。
• 手动设置类加载器：在异步任务的开头显式设置线程上下文类加载器：

CompletableFuture.supplyAsync(() -> {
    // 强制设置为应用类加载器
    Thread.currentThread().setContextClassLoader(YourApplicationMainClass.class.getClassLoader());
    if (someBean != null) {
        try {
            someReturnVal = methodCall();
        } catch (Exception e) {
            log.info("Log with reason: " + e.getMessage());
        }
    }
    return someReturnVal;
}, applicationThreadPool) // 传入Spring配置的线程池
.thenAccept(someReturnVal -> {
    try {
        SomeBean.saveToDB(someReturnVal);
    } catch (AccessException e) {
        log.info("log with reason: " + e.getMessage());
    }
});

2. 依赖配置问题（隐性缺失/冲突） #

虽然应用启动时正常，但可能存在以下依赖问题：

• commons-pool2的依赖范围被设置为provided，导致部署包中没有包含该jar，容器运行时无法加载类；
• 依赖版本冲突：比如EclipseLink依赖的commons-pool2版本和你项目中引入的版本不一致，导致类路径混乱。

解决方案： #

• 检查你的依赖管理文件（Maven/Gradle），确保commons-pool2的依赖范围是compile或runtime，并且版本适配：

<!-- Maven示例 -->
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-pool2</artifactId>
    <version>2.11.1</version> <!-- 选择与EclipseLink兼容的版本 -->
    <scope>runtime</scope>
</dependency>

• 确认部署包（如WAR包的WEB-INF/lib目录）中存在commons-pool2-x.x.x.jar。

3. 连接池配置与事务上下文问题 #

你的SaveToDB方法标注了@Transactional，但在CompletableFuture.thenAccept()中调用时，Spring事务注解可能无法生效——因为Spring事务是绑定到当前线程上下文的，异步线程没有继承主线程的事务上下文，导致EntityManager的使用状态异常，间接触发连接池的类加载问题。

解决方案： #

• 将事务逻辑移到同步方法中，或者使用Spring的@Async注解替代手动的CompletableFuture，让Spring管理异步线程的事务上下文：

// 定义异步服务类
@Service
public class AsyncDbService {
    @Async
    @Transactional
    public void saveToDbAsync(SomeBean someReturnVal) {
        try {
            em.persist(someReturnVal);
            em.flush();
        } catch (Exception e) {
            log.info("log with reason: " + e.getMessage());
        }
    }
}

// 在业务代码中调用
CompletableFuture.supplyAsync(() -> {
    // 原有逻辑
    return someReturnVal;
}).thenAccept(someReturnVal -> {
    asyncDbService.saveToDbAsync(someReturnVal);
});

4. 类加载器泄漏 #

运行一段时间后，应用的Web类加载器被容器回收，但异步线程仍然持有旧类加载器的引用，导致后续加载类时失败。

解决方案： #

• 避免在异步任务中持有应用类的强引用，确保任务完成后能被GC回收；
• 使用容器或Spring管理的线程池，避免自定义线程池导致的类加载器泄漏。

快速排查步骤 #

1. 打印异步线程和主线程的类加载器，对比是否一致：

log.info("Main thread classloader: " + Thread.currentThread().getContextClassLoader());
CompletableFuture.supplyAsync(() -> {
    log.info("Async thread classloader: " + Thread.currentThread().getContextClassLoader());
    // 原有逻辑
});

2. 检查部署包中是否存在commons-pool2的jar文件；
3. 临时禁用异步逻辑，改为同步调用，看是否还会出现错误，验证是否是异步环境导致的问题。

内容的提问来源于stack exchange，提问作者Rahul Pandey