Java Mysql jconnector将50%的时间花在com.myql.jdbc.utils.ReadAheadInputStream.fill（）上

我正在分析使用Spring、Hibernate和mysql java连接器的应用程序。VisualVM显示，当有1000个并行连接进行读取时，超过50%的CPU时间花费在

com.myql.jdbc.utils.ReadAheadInputStream.fill（）方法中

是否有任何优化可以加快速度？
如果没有其他信息，很难回答您的问题。这里有一些信息需要，应该先满足

您对CPU时间的估计是绝对的还是相对的？若
fill（）。但是，如果这个数字是使用VisualVM得到的，VisualVM报告了相对于应用程序花费时间的使用时间，那么可能是应用程序的其余部分没有做重要的工作

是否使用系统级工具确认这些分析测量？您可以使用
pidstat
、
mpstat
和
sar
交叉检查您是否在Linux上。我已经看到VisualVM将花在
SocketInputStream.socketRead0（）
方法中的时间标记为CPU时间，而
pidstat
没有确认这一点。我猜这是VisualVM本身或JVM行为中某些度量近似的结果。因此，使用操作系统工具进行交叉检查总是一个好主意
P>在其他建议的基础上，也要考虑使用更低的连接量（即20）。
处理如此大量的开放连接的开销很可能会稍微愚弄您的分析观察结果

最重要的是，确保您使用的是最新版本的Hibernate ORM。
我们使版本5.0+比以前的版本更智能，特别是在性能改进方面；-）改进每天都在应用，因此保持最新或至少尝试最新可能是一个容易的胜利。
VisualVM将一个线程视为在JVM认为它可以运行时使用CPU时间。这意味着任何不等待锁的线程或多或少都被认为是可运行的，包括在内核中等待I/O的线程！这就是
com.myql.jdbc.utils.ReadAheadInputStream.fill（）
中大量CPU使用的原因。因此，不是CPU问题，而是I/O问题

在JVM方面，您可以做一些事情，但不是很多简单的优化：

调整连接池大小。1000个并发查询太多了。除非你的MySQL实例真的很庞大，否则它将很难处理这种级别的负载，并且仅仅在查询之间切换会占用很多时间。尝试将池大小降低到250甚至50，并在那里进行基准测试
执行更少或更小的查询。如果你的应用程序很小，那么很明显，每个查询中的每一行都是必需的，但也许你的应用程序比这还要大。查询相同数据的不同地方是相同的，还是可以将两个不同的查询组合成一个同时满足这两个条件的查询
您是否将日志设置为调试级别？你是在用这些连接做什么，还是只是在做虚拟选择？另外，这个类委托给另一个输入流。从其中一个调用中查看堆栈跟踪会很有帮助。@Augusto我正在执行实际查询，每次返回大约200行。你是什么意思？在hibernate上还是在mysql上？真正的方法是java.net.SocketInputStream.read。我用谷歌搜索了一下，但没有多少关于如何改进它的提示。它听起来确实像是在等待数据库返回数据。问题可能出在数据库本身，您是否看到MySQL和它运行的盒子中的任何使用数据？1000个并发连接将占用大量内存。。如果它必须访问磁盘来进行这些查询，那么数据库将花费相当长的时间来响应。@Augusto是的，似乎是这样。我换了一台更强大的机器，性能越来越高，解决这个问题运气好吗？