java - 应用程序似乎卡在 SocketRead 上

Question

我们正在将一个应用程序从 Java 6 迁移到 Java 7。在高层，问题是它的速度较慢。

更详细地说，我们一直在升级类，因为分析器会告诉我们热点。此时我们有 java.net.SocketInputStream.socketRead0(Native Method) 在使用 jvisualvm 的采样器时显示了 42% 的使用率。

做线程转储，很多线程都有这个栈

"RMI TCP Connection(68)-192.168.1.198" daemon prio=5 tid=0x00007ff3279f3800 nid=0x49d2b runnable [0x000000013e279000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:152)
    at java.net.SocketInputStream.read(SocketInputStream.java:122)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
    - locked <0x00000007f881b7f0> (a java.io.BufferedInputStream)
    at java.io.FilterInputStream.read(FilterInputStream.java:83)
    at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:538)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - <0x0000000763e82c50> (a java.util.concurrent.ThreadPoolExecutor$Worker)

我对此的理解是应用程序卡在响应上。我无法判断它是来自数据库还是来 self 们的测试端点的响应。我们模拟 http 请求并在我们的测试中将它们发送到我们的应用程序。

谷歌搜索我尝试设置以下属性:

-Dsun.rmi.transport.tcp.responseTimeout=5000

-Djava.net.preferIPv4Stack=true

没有效果。

这里是我们设置中可能相关的内容的简要概述

• Centos 或 Mac(都有问题)
• mysql 5.1.73
• c3po
• hibernate 4.3.6

有什么想法吗？

Answer 1

我不知道这个套接字通信的上下文是什么，但很可能您看到的数字并不是真正的问题...

• 如果线程一直连接到套接字，在可用时读取数据并处理它，那么看到 socketRead0 的高使用率是正常的。这只是意味着 42% 的时间没有数据可用于处理，因此 socketRead0 阻塞等待数据(因此 42% 的线程 Activity 时间是在 socketRead0 方法中度过的)。事实上，在这种情况下，我建议将处理数据和读取数据拆分到两个单独的线程中(这会使读取线程在 socketRead0 中报告更高的使用率)。

• 如果 socketRead0 是临时“查询”的结果(也就是说，您的代码通过套接字连接定期请求数据)，那么 42% 就是这些数据请求所花费的时间(其中包括远程进程生成数据所花费的时间以及通过网络读取数据所花费的时间)。如果这个时间太多，您需要考虑加快套接字的另一端，或者它的吞吐量和/或延迟)。