请教一下，目前使用1.2.6版本，activeCount 这个全局变量，在我这边发现高并发单节点运行环境下，这个activeCount 会出现错误统计的情况，导致活跃链接有一部分永远在那，导致最后报错超过max。佐证是数据源活跃链接已经560了，但服务器连1521的TCP只有39个，数据库直接查会话也很正常，druid、plsql检测慢SQL均未发，也不存在长链接业务场景。晚上无人访问时，几乎还是无法下降。通过阅读源码，发现源码里有一处activeCount的时候没有上锁，不知道有没有其他用意，但这样似乎无法保证activeCount的时候hold的active一定为true,导致在activeCount--的场景中，需要判断hold的active必须为true才执行的逻辑要求无法保证，最终随着运行一段时间，积累出现假死的activeCount。目前druid显示最大并发11，之前运行期间不超过3，就没发生过明显的大量活跃链接无法下降的情况。
5条答案
按热度按时间pokxtpni1#
我好奇了一下，如果不加锁的话那问题可就非常大了，所以我去看了一下
1.2.6版本的DruidDataSource的源码。并没有发现你说的不加锁的情况，所有的activeCount++和activeCount--都是有加锁的。所以你的这个问题是怎么出现的，可能有其他的原因吧。4uqofj5v2#
首先很荣幸能得到您的答复。 1.2.6版本此方法的1690、1691行分别也对activeCount和holder.active进行了操作，但好像没有加局部锁；activeCount的减操作好像是根据holder.active的状态来判断的逻辑，个人理解holder.active和activeCount是需要逻辑紧耦合使用的，如果没有lock.lock()，是否存在某些场景下，activeCount++成功，但holder.active的状态未变更，导致最后无法通过holder.active的真假进行activeCount--。我在实际运行项目里确实发现了这个情况，那台服务器只有一个web应用在连数据库，本机连1521也只有20个，数据库会话数量也正常，但druid给出的当前活跃链接数已经超过了200…
________________________________ 发件人: suyh ***@***.***> 发送时间: 2022年1月3日 13:53 收件人: alibaba/druid ***@***.***> 抄送: hanyuekidd ***@***.***>; Author ***@***.***> 主题: Re: [alibaba/druid] activeCount 误判导致最终到达maxActive (Issue #4640) 我好奇 了一下，所以我去看了一下1.2.6 版本的DruidDataSource 的源码。并没有发现你说的不加锁的情况，所以的都activeCount++和activeCount-- 都有加锁的。所以你的这个问题是怎么出现的，可能 有其他的原因吧。 [image]< https://user-images.githubusercontent.com/24287740/147902745-5a3f41c3-2fc2-4434-aefd-0d5b3bc65350.png > ― Reply to this email directly, view it on GitHub<#4640 (comment)>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/AXDMTNKIDWE4C3PQA3UQKATUUE2U3ANCNFSM5LBIORAQ >. Triage notifications on the go with GitHub Mobile for iOS< https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 > or Android< https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub >. You are receiving this because you authored the thread.Message ID: ***@***.***>
webghufk3#
这是来自QQ邮箱的假期自动回复邮件。 您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。
ljsrvy3e4#
首先很荣幸能得到您的答复。 1.2.6版本此方法的1690、1691行分别也对activeCount和holder.active进行了操作，但好像没有加局部锁；activeCount的减操作好像是根据holder.active的状态来判断的逻辑，个人理解holder.active和activeCount是需要逻辑紧耦合使用的，如果没有lock.lock()，是否存在某些场景下，activeCount成功，但holder.active的状态未变更，导致最后无法通过holder.active的真假进行activeCount--。我在实际运行项目里确实发现了这个情况，那台服务器只有一个web应用在连数据库，本机连1521也只有20个，数据库会话数量也正常，但druid给出的当前活跃链接数已经超过了200
…
________________________________ 发件人: suyh ***@***.***> 发送时间: 2022年1月3日 13:53 收件人: alibaba/druid ***@***.***> 抄送: hanyuekidd ***@***.***>; Author ***@***.***> 主题: Re: [alibaba/druid] activeCount 误判导致最终到达maxActive (Issue #4640) 我好奇 了一下，所以我去看了一下1.2.6 版本的DruidDataSource 的源码。并没有发现你说的不加锁的情况，所以的都activeCount和activeCount-- 都有加锁的。所以你的这个问题是怎么出现的，可能 有其他的原因吧。 [image] https://user-images.githubusercontent.com/24287740/147902745-5a3f41c3-2fc2-4434-aefd-0d5b3bc65350.png ― Reply to this email directly, view it on GitHub<#4640 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXDMTNKIDWE4C3PQA3UQKATUUE2U3ANCNFSM5LBIORAQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Message ID: ***@***.***>
你所说的1690和1691 行界于[1624, 1704] 行之间，在1624 行(
lock.lockInterruptibly();)加了锁，然后在1704 行(lock.unlock();)将锁释放。svgewumm5#
请升级到新版本
https://github.com/alibaba/druid/releases