Java 对BoneCP中partitionCount的更好解释

从官方BoneCP文件：

partitionCount为了减少锁争用从而提高性能，每个传入的连接请求都会选择一个连接 来自具有线程关联性的池，即池[threadId% 分区计数]。这个数字越高，你的表现就越好 当你有很多短命的线程时，这将是一个很好的例子。 超过某个阈值后，这些池的维护将开始减少 对性能有负面影响（仅在以下情况下） 分区上的连接开始耗尽）

默认值：2，最小值：1，建议值：3-4（但非常特定于应用程序）

---

但它不是很清楚，也没有一个好的例子。我正在运行一个正常的web服务，有0-500个同步线程。这是一个很好的值，为什么？

因此BoneCP内部有连接池的分区计数。每次线程尝试使用连接时，它都会使用

thread.getId（）%partitionCount

并使用来自该池的连接。您总共将拥有

maxConnectionsPerPartition*partitionCount

连接数

为什么这会对绩效产生积极影响？为了不让两个线程同时在同一个连接上使用（显然这是不好的），BoneCP必须使用锁来释放或获取连接。但是在同一时间，所有其他想要执行相同操作的线程都必须等待该锁。因此，在某种意义上，您可以并行地释放或获取

partitionCount

连接数

设置为什么号码？我认为#of cores是一个好的开始，因为无论如何，你不会有更多的工作并行进行。但除此之外，试着预测有多少线程将竞相连接，测量并重复

---

顺便说一句，世界上大部分地区已经依赖c3po超过十年了，并且分区计数基本上设置为1。所以你不会错得很厉害。

BoneCP作者：这个解释很完美。我只想补充一点，拥有更多的分区也意味着每个分区通常配置的连接更少（因为它们是分开的）。如果一个线程试图命中一个耗尽的分区，那么它就会溢出，尝试从其他分区获取连接，因此在某个时候它实际上开始变慢。正如javadocs所说，最多坚持3-4个左右（核心数也是一个很好的提示）。@user149789和Mirko，因此对于我们这些在云微实例上运行基于JVM的应用程序的人来说，单核心是标准，听起来分区计数应该设置为1。今天进行基准测试时，我惊讶地发现数据库中使用的最大连接数不是48（配置3 partitionCount*16 maxConnectionsPerPartition），而是16，如果我必须处理并行连接以执行至少2个语句操作，那么这些连接数将是~30。你能告诉我分区的大小吗？是不是要设置为30？另外，您是否可以告知设置BoneCPDataSource所涉及的其他参数？