我刚刚用akka编写了一个JDBC连接池。

它使用一个参与者来保存实际数据库连接的"maxpoolsize"集合。调用者向池参与者请求连接，并接收一个Future[Connection]，连接的状态变为"忙碌"，直到调用者将其返回到connection.close上的池。如果所有连接都忙，则新的传入连接请求将放置在等待队列中(也由池参与者持有)。稍后，当返回连接时，将满足等待请求。

这个逻辑在Akka中的实现非常简单，只有几十行代码。但是，当使用bonecp多线程测试来测试性能时(即调用方close在满足getConnection返回的Future[Connection]时立即进行连接。基准的traversed所有close请求和Await对于结果Future，我发现akka版本比其他连接池实现(如tomcat jdbc、bonecp甚至commons dbcp)慢。

我尝试过的调优：

但没有明显的改善。

我的问题是：

要回答问题1，这不是AKKA在速度方面的优势所在。您基本上解决了一个问题，这个问题通常是通过为多个读写器优化的并发数据结构来解决的，并通过一个参与者将其序列化。

另一种方法是创建路由器，它将产生几个从属参与者，每个参与者代表一个连接。

但要注意，可能存在潜在的种族条件。

另外，您使用的是什么版本的scala和akka？

对于高度并行计算，AKKA可能是一个很好的选择，而JDBC连接池并不是高度并行计算的一个好例子。