17

我们有一个客户端服务器应用程序，1 个服务器，大约 10 个客户端。它们使用自定义查询通过 tcp 套接字进行通信。

系统已经运行了好几个月了，但是在某个时间点，在每天大约 50s 的定时服务器 FULL GC 之后，我们发现客户端发送的查询和服务器收到的响应之间的时间很长，> 10-20 秒。大约 3 小时后，系统恢复正常，一切都恢复正常。

在调查该问题时，我们发现：

  1. 客户端和服务器上都没有垃圾收集问题
  2. 服务器上的查询处理时间很短。
  3. 服务器上的负载很高。
  4. 网络带宽未饱和。
  5. 在 FULL GC 期间没有重置连接（在此之前，每天的 FULL GC 是正常事件）
  6. 机器和操作系统最近从 Centos 6（内核 2.6.32）更改为 Centos 7（内核 3.10.0），但新配置经过了广泛的测试。Oracle JDK 版本也从 1.7.65 更改为 1.7.75。

我们在服务器上进行了线程转储：

java.lang.Thread.State: RUNNABLE
    at java.io.FilterInputStream.read(FilterInputStream.java:83)
    at util.network.BytesBasedSocketConnection$ReadConnectionRunnable.run(BytesBasedSocketConnection.java:293)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
    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)

FilterInputStream.read()如下：

    public int read() throws IOException {
    return in.read();
}

在in我们的代码中是一个BufferedInputStream.

问题是：为什么在 Full GC 暂停后大多数连接变慢了？为什么堆栈跟踪以 结尾FilterInputStream.read()？它不应该BufferedInputStream在套接字输入流或套接字输入流中的某个地方结束吗？此读取会导致服务器负载高吗？

我们用来阅读的代码：

int constructLength = _socketDIS.readInt();
ByteArrayOutputStream constructBOAS = new ByteArrayOutputStream(constructLength);
for (int i = 0; i != constructLength; i++)
      constructBOAS.write(_socketDIS.read());
constructBOAS.close();
byte[] bytes = constructBOAS.toByteArray();

在哪里：

_socketDIS = new DataInputStream(new BufferedInputStream(_socket.getInputStream()));

这是来自运行良好的客户端连接的堆栈跟踪：

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 <0x00007f522cbebca8> (a java.io.BufferedInputStream)
    at java.io.DataInputStream.readInt(DataInputStream.java:387)
    at util.network.BytesBasedSocketConnection$ReadConnectionRunnable.run(BytesBasedSocketConnection.java:287)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
    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)

更新：

关于 EJP 答案：

  1. 没有涉及 EOS，连接已建立，但速度非常慢

  2. 即使有 EOS，我也看不到代码如何在 EOS 上旋转，for它受constructLength值的限制。但是，建议的改进仍然有效。

  3. 存在问题的堆栈跟踪以对 ( ) 的读取结束，该DataInputStream( (_socketDIS.read()) 继承自FilterInputStream.read()，请参见上面的代码。DataInputStream，不是BufferedInputStream错过了read()。这里FilterInputStream.read()有一个in.read()被调用的 a BufferedInputStream，这个有自己read()定义的方法。但是堆栈跟踪在中间停止，没有到达BufferedInputStream.read(). 为什么？

4

4 回答 4

7

一次读取一个字节会浪费 CPU。扔掉这个：

int constructLength = _socketDIS.readInt();
ByteArrayOutputStream constructBOAS = new ByteArrayOutputStream(constructLength);
for (int i = 0; i != constructLength; i++)
      constructBOAS.write(_socketDIS.read());
constructBOAS.close();
byte[] bytes = constructBOAS.toByteArray();

并使用这个：

int constructLength = _socketDIS.readInt();
byte[] bytes = new byte[constructLength];
_socketDIS.readFully(bytes);

NB_socketDIS显然不是aBufferedInputStream而是 aDataInputStream,是无缓冲的。

编辑

为什么堆栈跟踪以 FilterInputStream.read() 结尾？

仔细看。BufferedInputStream没有实现所有三个 read() 重载。其中一个，我忘记了，是在基类 FilterInputStream 中实现的，另外两个重载调用它。

它不应该在 BufferedInputStream 的某个地方结束吗

不，见上文。

或在套接字输入流中？

是的，如果它被阻塞了，但它不是，可能是因为你在流的末尾旋转，因为你的代码很糟糕。

此读取会导致服务器负载高吗？

是的。

于 2015-05-20T12:24:04.537 回答
3

堆栈跟踪显示您正在使用ScheduledThreadPoolExecutor. 我建议你研究一下时间表。延迟很可能仅仅是因为阅读是按某种时间表进行的——这对我来说似乎很愚蠢。

于 2015-05-20T10:51:58.567 回答
1

这更像是一个扩展评论，但评论太长了，所以我会在答案中提供。

正如您所注意到的，在 FilterInputStream.read() 中间显示一个线程的线程转储是不寻常的。虽然它可能是偶然发生的，虽然被覆盖的 FilterInputStream.read() 被解析为 BufferedInputStream.read()，但偶然发生似乎不太可能。

鉴于这发生在完全垃圾回收之后，在我看来，解决 FilterInputStream 调用需要更长的时间，因为 BufferedInputStream 类在完全垃圾回收期间被移动或卸载。例如，如果在完全垃圾回收发生时碰巧没有正在使用的 BufferedInputStream 对象，则 BufferedInputStream 类可能已被卸载，当需要其 read() 方法时需要加载类。这可能是您看到的延迟的原因，至少有一次。

在某些情况下，当最后一个实例被垃圾回收时，类可能会被卸载，即使没有完整的垃圾回收。如果 BufferedInputStream 类在每次使用后以某种方式被卸载并在下次使用时重新加载，这可以解释您所说的症状，但我通常不会期望会发生这种情况。

如果您使用的是虚拟内存，那么保存 BufferedInputStream 类的内存页面也可能出现抖动，这可能是因为在完全垃圾回收期间该类被重新定位。如果您在此期间有任何有关内存使用的记录，它们可能值得一看。

于 2015-05-23T00:13:05.647 回答
-1

我想您必须尝试刷新它才能在流中读取和写入而不会出现错误或减慢连接速度。

于 2015-05-28T22:44:38.757 回答