Spring Boot中LDAPTemplate的PoolingContextSource在空闲场景下超量创建连接问题排查

看起来你遇到的是Spring LDAP连接池在低流量/空闲时段的超量创建连接问题，结合你给出的配置和现象，我来帮你拆解几个最可能的原因，以及对应的排查和解决方向：

一、核心矛盾：空闲连接失效未及时清理+借连接时的强校验导致重复创建 #

咱们先对齐几个关键配置和现象的逻辑：
你当前的配置是：

• minEvictableIdleTimeMillis = 90000（空闲90秒以上的连接会被回收）
• timeBetweenEvictionRunsMillis = 15000（每15秒跑一次空闲连接回收线程）
• testOnBorrow = true（每次借连接前都会校验连接有效性）

而现象是：高流量时池正常，但空闲场景下会创建超过配置上限的连接；关闭空闲回收（timeBetweenEvictionRunsMillis=-1）或设testWhileIdle=false就恢复正常。

最可能的根因是：

你的LDAP服务器会主动断开短于90秒的空闲连接（比如很多LDAP服务如AD、OpenLDAP默认都有空闲超时策略，可能比你设置的90秒更短），导致池里的空闲连接在未到回收时间前就已经失效了。

这时候当有新请求来借连接时：

1. 连接池认为池里还有空闲连接（失效的那些），尝试借出
2. 因为testOnBorrow=true，校验时发现连接已经失效（被LDAP服务器断开），就直接丢弃这个失效连接
3. 连接池不得不创建新的连接来满足请求
4. 而那些失效连接要等满90秒才会被回收线程清理掉，在这期间如果有多次请求，就会不断创建新连接，最终实际与LDAP服务器的连接数超过了你配置的总连接上限。

那为什么关闭空闲回收或设testWhileIdle=false就正常？

• 关闭空闲回收后，池里的失效连接不会被主动回收，但testOnBorrow会在借连接时直接丢弃失效连接并创建新的；但因为没有回收线程在后台频繁操作，加上低流量下请求少，不会短时间内积累大量失效连接，所以不会出现超量创建的情况。
• 设testWhileIdle=false时，空闲回收线程只会按空闲时间回收连接，不会校验连接有效性，避免了回收线程误判或者提前清理连接的情况（不过这只是绕过了问题，不是根本解决）。

二、具体的排查和解决建议 #

1. 先确认LDAP服务器的空闲超时时间 #

先去查你的LDAP服务器（比如AD、OpenLDAP）的空闲连接超时配置，看是不是比你设置的minEvictableIdleTimeMillis=90000更短。如果是的话，把minEvictableIdleTimeMillis调整为比服务器超时短10-20秒（比如服务器超时是60秒，你就设为50000），这样回收线程会在LDAP服务器断开连接之前，就把空闲连接回收掉，从根源上避免池里积累失效连接。

2. 开启testWhileIdle参数 #

把testWhileIdle设为true，这样空闲回收线程每15秒跑一次时，不仅会回收空闲超90秒的连接，还会校验每个空闲连接的有效性——如果发现连接已经失效（被服务器断开），不管它空闲了多久，都会直接回收。这样池里的失效连接会被及时清理，不会等到借连接时才被发现，自然就不会出现不断创建新连接的情况。

3. 配合开启testOnReturn #

可以同时把testOnReturn设为true，这样当连接被归还到池里时，会立刻校验有效性，如果已经失效就直接丢弃，不让它回到池里。这样能进一步保证池里的连接都是可用的，减少借连接时的校验和重建开销。

4. 检查连接池配置是否真的生效 #

有时候我们的配置可能被Spring Boot的自动配置或者其他地方的配置覆盖了，建议你在应用启动时，打印出PoolingContextSource的实际参数（比如通过日志输出maxTotal、minEvictableIdleTimeMillis、testWhileIdle等的值），确认你的配置真的被应用了。

5. 排查是否存在连接泄漏 #

虽然高流量下正常，但也可以排查下是否有连接泄漏的情况：比如代码中使用LDAPTemplate时，有没有因为异常导致连接没有被正确归还？可以用连接池的监控功能（比如Apache Commons Pool2的JMX监控）查看连接的借用、归还统计，看是否有未归还的连接。

三、总结 #

核心问题就是失效空闲连接未被及时清理，加上借连接时的强校验导致重复创建连接。调整空闲回收时间匹配LDAP服务器的超时，再开启testWhileIdle及时清理失效连接，应该就能彻底解决这个问题。

内容来源于stack exchange