线程池实现填充短信_填充一个池需要多少个线程？

最新推荐文章于 2022-11-03 14:39:57 发布

dnc8371

最新推荐文章于 2022-11-03 14:39:57 发布

阅读量155

点赞数

文章标签：数据库 java mysql 多线程 python

原文链接：https://www.javacodegeeks.com/2013/06/how-many-threads-does-it-take-to-fill-a-pool.html

版权

线程池实现填充短信

在最近几个月中，我们一直看到很小但持续的操作失败，但有一个奇怪的异常– org.springframework.jdbc.CannotGetJdbcConnectionException –“无法获得JDBC连接；嵌套异常是java.sql.SQLException：客户端尝试检出Connection的尝试已超时。 ”

我们的自然假设是，我们在C3P0连接池中存在某种争用，尝试获取连接的客户端必须等待该争用可用。我们最好的猜测是正是这种争执导致了超时。

因此，当然，我们要做的第一件事是增加连接池中的最大连接数。但是，无论我们将限制设置得多么高，它都无济于事。然后，我们尝试更改连接的超时参数。那没有产生任何更好的结果。

此时，情报已经确定下来，并且由于猜测似乎没有用，因此我们决定进行测量。使用连接池上的一个简单包装器，我们看到即使连接池中有空闲连接，我们仍然会得到签出超时。

调查连接池开销

为了研究连接池的开销，我们执行了一个基准测试，该基准测试由6个回合组成，每个回合包括20,000个SQL操作（读/写比为1:10），使用20个线程和20个连接的连接池来执行。使用具有20个连接的池使用20个线程意味着资源（连接）上没有争用。因此，任何开销都是由连接池本身引起的。

我们忽略了第一次（预热）运行的结果，而取了随后5次运行的统计数据。从这些数据中，我们收集连接签出时间，连接释放时间和总池开销。

基准项目代码可以在以下位置找到： https : //github.com/yoavaa/connection-pool-benchmark

我们测试了3个不同的连接池：

C3P0 – com.mchange：c3p0：0.9.5-pre3 – C3P0DataSourceBenchmark类
Bone CP – com.jolbox：bonecp：0.8.0-rc1 –类BoneDataSourceBenchmark
Apache DBCP – commons-dbcp：commons-dbcp：1.4 –类DbcpDataSourceBenchmark

（在该项目中，还有一个我自己的实验性异步池的基准测试-https: //github.com/yoavaa/async-connection-pool 。但是，出于本文的目的，我将忽略它）。

为了自己运行基准测试，您应该使用下表设置MySQL

CREATE TABLE item (
  file_name     varchar(100) NOT NULL,
  user_guid     varchar(50) NOT NULL,
  media_type    varchar(16) NOT NULL,
  date_created  datetime NOT NULL,
  date_updated  timestamp AUTO_INCREMENT NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY(file_name)
)

然后更新Credentials对象以指向此MySQL安装。

运行基准测试时，结果示例如下：

run, param, total time, errors, under 1000 nSec,1000 nSec - 3200 nSec,3200 nSec - 10 µSec,10 µSec - 32 µSec,32 µSec - 100 µSec,100 µSec - 320 µSec,320 µSec - 1000 µSec,1000 µSec - 3200 µSec,3200 µSec - 10 mSec,10 mSec - 32 mSec,32 mSec - 100 mSec,100 mSec - 320 mSec,320 mSec - 1000 mSec,1000 mSec - 3200 mSec,other
0, acquire,29587,0,0,5,1625,8132,738,660,1332,1787,2062,2048,1430,181,0,0,0
0, execution, , ,0,0,0,0,0,0,0,1848,6566,6456,5078,52,0,0,0
0, release, , ,0,8,6416,9848,3110,68,77,115,124,148,75,11,0,0,0
0, overhead, , ,0,0,49,4573,5459,711,1399,1812,2142,2157,1498,200,0,0,0
1, acquire,27941,0,0,125,8153,499,658,829,1588,2255,2470,2377,1013,33,0,0,0
1, execution, , ,0,0,0,0,0,0,6,1730,6105,6768,5368,23,0,0,0
1, release, , ,0,49,15722,3733,55,42,69,91,123,101,14,1,0,0,0
1, overhead, , ,0,0,2497,5819,869,830,1610,2303,2545,2448,1042,37,0,0,0

此信息已导入Excel文件（也包含在基准项目中）以进行分析。

C3P0

最初在C3P0中，我们在生产环境中看到了原始异常。让我们看看它如何执行：

阅读图表：

前三个图表（获取，发布，开销）是基于性能的存储桶图表。 Y轴表示在一定时间范围内完成的操作数（在X轴上显示）。 默认的经验法则是，左侧的条形越高，效果越好。 第四^个图表是瀑布图，其中每个水平线表示一个DB操作。 棕色表示等待获取连接的时间，绿色表示执行数据库操作的时间，蓝色表示将连接返回到连接池的时间。

从图表中可以看出，通常，C3P0在3.2-10微秒内获得连接，并在3.2-10微秒内释放连接。那绝对是一些令人印象深刻的表现。但是，C3P0在约3.2-32毫秒处还有另一个峰值，而长尾巴则高达320-1000毫秒。正是第二个高峰导致了我们的例外。

C3P0怎么了？是什么原因导致了这种极小但相当大的超长操作百分比，而大多数时候却表现惊人？纵观4 ^个图可以为我们指出了答案的方向。

第4 ^个图表从左上角到右下角都有一条清晰的对角线，表明总体上，连接获取是按顺序开始的。但是我们可以识别出一些奇怪的东西–我们可以看到棕色的三角形，表示当多个线程试图获取连接时，第一个线程比后续线程等待更多时间的情况。这转化为用于获取连接的两个性能“组”。一些线程极其快速地获得连接，而有些线程则饿死等待连接，而较后的线程的请求则得到了较早的答复。

早期线程比后续线程等待更长的时间的这种行为意味着不公平的同步。事实上，挖掘到C3P0代码时，我们已经看到了收购的连接的过程中，C3P0使用“ 同步 ”关键字三次。在Java中，' synceded '关键字创建了不公平的锁，这可能导致线程饥饿。

稍后我们可能会尝试使用公平锁定来修补C3P0。如果这样做，我们自然会分享我们的发现。

此基准测试的C3P0配置：