应用程序似乎挂在SocketRead上

时间:2014-11-12 03:30:26

标签: java sockets rmi

我们正在将应用程序从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)

我对此的理解是应用程序挂在响应上。我不知道它是来自数据库还是来自我们的测试端点的响应。我们模仿http请求并在我们的测试中将它们发送到我们的应用程序中。

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

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

-Djava.net.preferIPv4Stack=true

没有效果。

以下是我们设置中可能相关内容的快速概述

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

有什么想法吗?

1 个答案:

答案 0 :(得分:1)

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

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

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