1.druid连接池中的码解连接数与预期不一致的一次分析
2.druid源码学习笔记9_testOnBorrow&testOnReturn&testWhileIdl
3.弹性数据库连接池探活策略调研 (二)——Druid | 京东云技术团队
4.简直了！通过源码告诉你阿里的码解数据库连接池Druid为啥如此牛逼
5.源码详解系列(四) ------ DBCP2的使用和分析（包括JNDI和JTA支持）已停更
6.阿里巴巴Druid，轻松实现MySQL数据库加密！码解
druid连接池中的码解连接数与预期不一致的一次分析
深入剖析druid连接池连接数与预期不一致的原因与解决方案 在排查生产环境cat监控显示部分应用SQL执行耗时长的问题时，我们发现部分应用节点在运行一段时间后，码解数据库连接池中的码解java中math类源码实际连接数与应用中配置的参数不一致。主要表现为连接池中的码解可用连接总数远小于应用配置的初始连接数与最小空闲连接数。这导致了新建连接耗时增加，码解线程阻塞状态出现，码解影响性能，码解不利于应对外部瞬间的码解并发压力。条码组项目使用的码解是druid框架，但使用版本较为杂乱，码解包括1.0.、码解1.1.、码解1.1.。基于此，本文旨在分析druid如何对空闲连接进行回收，以及提供相应的配置建议与jar包版本建议。 详细分析过程 通过对源码的反编译分析，我们发现druid框架在应用启动后启动了多个处理线程，其中Druid-ConnectionPool-Destroy-*线程专门用于回收空闲连接。不同版本的使用配置及处理逻辑存在差异。以1.0.与1.1.版本为例进行对比分析。 在1.0.版本中，回收线程按照配置的时间间隔timeBetweenEvictionRunsMillis进行轮询。回收空闲连接的判断逻辑包含如下步骤：遍历连接池中的所有连接。
获取超过最小空闲连接数的数量checkCount（连接池总数减去最小空闲连接数）。
获取当前连接的空闲时间idleMillis（当前时间减去上一次连接使用的时间）。
判断idleMillis是六端影视源码否小于minEvictableldleTimeMillis（默认分钟），小于则退出循环，否则继续后续处理。
如果checkCount大于0，将超过最小空闲连接数的连接放入待销毁集合（进行回收）。
如果idleMillis大于maxEvictableIdleTimeMillis，即使连接池连接数小于最小空闲连接数，当前连接也会被放入待销毁集合。
在1.1.版本中，新增了判断逻辑：idleMillis需要同时满足小于minEvictableldleTimeMillis（默认分钟）与keepAliveBetweenTimeMillis（默认2分钟）时，才会退出循环。
配置keepalive为true时，idleMillis大于keepAliveBetweenTimeMillis，当前连接会被维护到保活集合中，以确保连接可用，避免意外回收。
分析总结 结合项目现有的配置和依赖的jar包版本，连接池中的连接数不总是与初始连接数或最小空闲连接数保持一致。在使用1.0.、1.1.版本的应用中，如果SQL请求不是非常稀少，则能维持连接池中的连接数与配置一致。然而，使用1.1.版本、处理SQL请求不是非常频繁的应用，空闲连接更容易被回收。关键原因在于缺少关键配置（keepalive未配置），导致默认参数下更容易回收连接。 版本建议 建议统一升级使用1.1.版本，并主动排除项目中依赖的59pic 源码其他版本，以防版本冲突。对于使用1.1.或更高版本的应用，确保添加keepalive=true配置。 Spring Boot项目配置示例：spring.datasource.druid.keep-alive=truedruid源码学习笔记9_testOnBorrow&testOnReturn&testWhileIdl
druid源码中，关于testOnBorrow、testWhileIdle和testOnReturn的属性配置值得重点关注。在1.2.9版本后，这些属性的默认值与早期wiki中的记录有所不同。testOnBorrow的默认值从true变为false，而testWhileIdle的默认值则从false变为true。这表明代码在年后可能进行了更新，但wiki尚未同步更新。 testOnBorrow主要在getConnectionDirect方法中起作用，当设置为true时，获取连接后会执行validationQuery检查连接是否可用。如果连接不可用，将重新获取。而testWhileIdle则在连接空闲时间达到timeBetweenEvictionRunsMillis时执行验证，同样用于检查连接状态。 testWhileIdle与testOnBorrow互斥，如果两者都为true，仅执行testOnBorrow。计算空闲时间的规则涉及checkExecuteTime、lastKeepTimeMillis和当前时间的比较。 testOnReturn属性在DruidPooledConnection#close()方法，即归还连接时被调用。当设置为true时，回收连接后会检查其状态，如连接未关闭，汽车官网源码会执行validationQuery。如果连接不可用，会关闭并计数，否则继续归还操作。 总结如下：testOnReturn在连接归还时检查，默认为false。
testOnBorrow和testWhileIdle在连接借用时检查，早期testOnBorrow为true，testWhileIdle为false，但新版本可能出于性能考虑进行了调整。
弹性数据库连接池探活策略调研 (二)——Druid | 京东云技术团队
在上篇文章中，我们探讨了 HikariCP 连接池的探活策略，现在我们将转向另一个流行的数据库连接池——Druid。京东云技术团队将为您揭示如何在使用Druid时实现最佳的弹性数据库连接池探活策略，以及其不同版本间的参数调整与实现逻辑。
Druid的探活机制复杂且版本间差异明显，配置参数众多。核心的探活逻辑主要集中在两个源码函数中。要确保探活策略生效，需理解以下几个关键参数：testOnBorrow、testWhileIdle和timeBetweenEvictionRunsMillis。在高并发场景下，推荐配置testWhileIdle以减少性能消耗。
Druid的getConnectionDirect函数在取连接时会进行探活检测，如果testOnBorrow为true，每次都会检查连接有效性。当testOnBorrow为false且testWhileIdle为true时，会根据timeBetweenEvictionRunsMillis来判断连接是否失效，若超过设定时间，app用户中心源码则进行探活。在版本1.1.及以上，保持连接功能（keepAlive）在minEvictableIdleTimeMillis设置小于分钟时，有助于高效探活并防止网关连接关闭。
在低版本中，如1.0.9，探活主要依赖于testOnBorrow或testWhileIdle，不支持keepAlive。而在1.1.和1.1.9版本中，shrink方法的逻辑有所调整，引入了keepAliveBetweenTimeMillis参数，增加了对keepAlive的控制。1.1.版本则进一步优化了探活过程，不仅关闭无效连接，还会补充连接以维持最小连接数。
总结来说，Druid的探活策略在不同版本中需灵活配置，建议在高并发场景下使用1.1.或更高版本，配置testWhileIdle以提高性能，同时根据需求选择是否启用testOnBorrow或使用keepAlive来保证连接的可用性。对于使用Druid连接池的线上应用，推荐依据实际需求选择合适的版本和参数设置。
以上内容由京东零售王雷鑫提供，出自京东云开发者社区，转载请注明原作者和来源。
简直了！通过源码告诉你阿里的数据库连接池Druid为啥如此牛逼
druid数据库连接池的强大之处在于其高效管理和丰富的功能。它通过复用连接减少资源消耗，具备连接数控制、可靠性测试、泄漏控制和缓存语句等标准特性，同时还扩展了监控统计和SQL注入防御等功能。
以入门需求为例，创建Maven项目，引入必要的依赖如JDK、maven、IDE，以及mysql-connector-java和druid。在项目中，通过JDBCUtil初始化连接池并获取连接，进行简单的增删改查操作。在web应用中，可以使用JNDI获取DruidDataSource，如在tomcat 9.0.容器下运行。
druid的监控统计功能强大，如StatFilter支持合并SQL、慢SQL记录和多个数据源监控数据的统一。StatViewServlet用于展示监控信息，配置WebStatFilter则能收集web-jdbc关联监控数据。同时，WallFilter用于防御SQL注入，提供定制化的参数配置选项。
druid的源码分析显示，它在连接池管理、配置方式的灵活性以及异常处理等方面展现出独特之处。尽管配置方式多样，但推荐优先使用最常见的方式，如properties文件。然而，过多的配置选项和缺乏统一的管理方式是其设计上的一个挑战。
总而言之，druid凭借其强大的功能和灵活的配置，为数据库连接池管理提供了高效且实用的解决方案，是阿里巴巴数据库连接池中的佼佼者。
源码详解系列(四) ------ DBCP2的使用和分析（包括JNDI和JTA支持）已停更
DBCP是一个用于创建和管理数据库连接的工具，通过连接池复用连接以减少资源消耗。它具备连接数控制、连接有效性检测、连接泄露控制和缓存语句等功能。Tomcat内置连接池、Spring团队推荐使用DBCP，阿里巴巴的druid也是基于DBCP开发的。 DBCP支持通过JNDI获取数据源，并且可以获取JTA或XA事务中的连接对象，用于两阶段提交（2PC）的事务处理。本篇文章将通过例子来解释如何使用DBCP。 以下是文章的详细内容：使用例子需求
本例将展示如何使用DBCP连接池获取连接对象，并进行基本的增删改查操作。工程环境
JDK：1.8.0_
maven：3.6.1
IDE：eclipse 4.
mysql-connector-java：8.0.
mysql：5.7.
DBCP：2.6.0
主要步骤
创建Maven项目，打包方式为war（war也可以是jar，这里选择war是为了测试JNDI功能）。
引入DBCP相关依赖。
在resources目录下创建dbcp.properties文件，配置数据库连接参数及连接池基本参数。
编写JDBCUtils类，实现初始化连接池、获取连接、管理事务和资源释放等功能。
创建测试类，实现基本的增删改查操作。
配置文件详解
dbcp.properties文件包含数据库连接参数和连接池基本参数，如数据库URL、用户名、密码、连接池大小等。其中，数据库URL后面添加了参数以避免乱码和时区问题。建议根据项目需求调整参数设置。基本连接属性
数据库URL
用户名
密码
连接池大小
缓存语句（在MySQL下建议关闭）
连接检查参数（建议开启testWhileIdle，避免性能影响）
事务相关参数（通常使用默认设置）
连接泄漏回收参数
其他参数（较少使用）
源码分析
DBCP主要涉及以下几个类：BasicDataSource：提供基本的数据库操作数据源。
BasicManagedDataSource：BasicDataSource的子类，用于创建支持XA事务或JTA事务的连接。
PoolingDataSource：BasicDataSource中实际调用的数据源，用于管理连接。
ManagedDataSource：PoolingDataSource的子类，用于支持XA事务或JTA事务的连接。
使用DBCP连接池创建连接时，首先创建BasicDataSource对象，初始化配置参数。然后从连接池中获取连接。连接获取过程涉及到数据源和连接池的创建，连接对象的包装和回收。通过JNDI获取数据源对象需求
使用JNDI获取DBCP数据源对象，以PerUserPoolDataSource和SharedPoolDataSource为例。为了在tomcat容器中测试，需要配置JNDI上下文。引入依赖
引入JNDI相关的依赖。
编写context.xml文件，配置JNDI上下文。
在web.xml中配置资源引用，将JNDI对象与web应用绑定。
测试结果
打包项目并部署到tomcat上运行，通过访问指定的jsp页面，验证JNDI获取数据源对象的正确性。使用DBCP测试两阶段提交
介绍如何使用DBCP实现JTA事务的两阶段提交（2PC）。使用DBCP的BasicManagedDataSource类支持事务处理。通过测试代码验证了2PC的正确性。 以上内容涵盖了DBCP的使用、配置、源码分析、JNDI集成以及两阶段提交的实现，为开发者提供了全面的参考。阿里巴巴Druid，轻松实现MySQL数据库加密！
面对源码安全与数据库信息保护的需求，数据库密码加密显得尤为重要。一旦源码泄漏，数据库密钥可能随之暴露，威胁数据安全。为解决这个问题，我们可以借助阿里巴巴的Druid工具轻松加密。
Druid是一款强大的Java数据库连接池，它不仅提供了监控和扩展功能，还内置了数据库密码加密特性。通过使用Druid，我们可以简单地保护数据库密码，即使源码被获取，密码也保持加密状态。
加密过程分为几个步骤：首先，项目在未加密前的交互是直接使用明文密码；而使用Druid后，会通过ConfigTools类生成公钥和密文，将明文密码转换为密文。然后，将公钥和密文添加到项目配置文件中，确保数据库连接时使用加密后的密码。
然而，需要注意的是，直接在配置文件中存储公钥和密文并不安全，因为这相当于公开了钥匙。正确的做法是在生产环境中动态设置公钥，避免密码还原。例如，开发环境可通过启动参数传递公钥，生产环境则通过jar包启动时提供。
总的来说，Druid的加密机制简化了这个过程，无需编写额外代码，仅需添加依赖、生成密文并配置，项目运行时Druid会自动处理解密，实现了MySQL密码的加密和自动解码。
druid 物理关闭数量 始终是0
我也发现这个问题
跟了一下源码
removeAbandonedTimeout
这个属性不管是否配置
初始化init方法调用后
removeAbandonedTimeout的值是
也就是使用的DruidAbstractDataSource里面的默认值
protected volatile boolean removeAbandoned;
protected volatile long removeAbandonedTimeoutMillis = * ;