我用了很多客户端向服务器发送请求，一个客户端每秒大约1000个请求，服务器的CPU很快就升到600%(8核)，并一直保持这种状态。当我使用jstack打印流程内容时，发现SelectorImpl是BLOCKED状态。记录如下:

nioEventLoopGroup-4-1 prio=10 tid=0x00007fef28001800 nid=0x1dbf waiting for monitor entry [0x00007fef9eec7000]
java.lang.Thread.State: BLOCKED (on object monitor)
at sun.nio.ch.EPollSelectorImpl.doSelect(Unknown Source)
- waiting to lock <0x00000000c01f1af8> (a java.lang.Object)
    at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
    - locked <0x00000000c01d9420> (a io.netty.channel.nio.SelectedSelectionKeySet)
    - locked <0x00000000c01f1948> (a java.util.Collections$UnmodifiableSet)
    - locked <0x00000000c01d92c0> (a sun.nio.ch.EPollSelectorImpl)
    at sun.nio.ch.SelectorImpl.select(Unknown Source)
    at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:635)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:319)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
    at java.lang.Thread.run(Unknown Source)

高CPU与此有关吗？另一个问题是，当我连接很多客户端时，发现有一些客户端会连接，报错如下:

"nioEventLoopGroup-4-1" prio=10 tid=0x00007fef28001800 nid=0x1dbf waiting for monitor entry [0x00007fef9eec7000]
java.lang.Thread.State: BLOCKED (on object monitor)
at sun.nio.ch.EPollSelectorImpl.doSelect(Unknown Source)
- waiting to lock <0x00000000c01f1af8> (a java.lang.Object)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
- locked <0x00000000c01d9420> (a io.netty.channel.nio.SelectedSelectionKeySet)
- locked <0x00000000c01f1948> (a java.util.Collections$UnmodifiableSet)
- locked <0x00000000c01d92c0> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(Unknown Source)
at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:635)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:319)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
at java.lang.Thread.run(Unknown Source)

生成client是使用线程池完成的，并且设置了连接超时，但是为什么会频繁连接超时呢？是为诉讼事业服务？

    public void run() {

    System.out.println(tnum + " connecting...");
    try {
        Bootstrap bootstrap = new Bootstrap();
        bootstrap.group(group)
        .channel(NioSocketChannel.class)
        .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 30000)
        .handler(loadClientInitializer);

        // Start the connection attempt.
        ChannelFuture future = bootstrap.connect(host, port);
        future.channel().attr(AttrNum).set(tnum);
        future.sync();
        if (future.isSuccess()) {
            System.out.println(tnum + " login success.");
            goSend(tnum, future.channel());
        } else {
            System.out.println(tnum + " login failed.");
        }
    } catch (Exception e) {
        XLog.error(e);
    } finally {

//group.shutdownGracefully();

}

最佳答案

High CPU has something to do with this?

可能是。我会按照以下方式诊断此问题(在 Linux 机器上):

查找占用 CPU 的线程

使用 pidstat 我可以找到哪些线程正在占用 CPU 以及在何种模式(用户/内核)下花费了时间。

$ pidstat -p [java-process-pid] -tu 1 | awk '$9 > 50'

此命令显示线程占用了至少 50% 的 CPU 时间。您可以使用 jstack、VisualVM 或 Java Flight Recorder 检查这些线程正在做什么。

如果 CPU-hungry 线程和 BLOCKED 线程相同，则 CPU 使用似乎会引起争用。

查找连接超时原因

基本上，如果两个操作系统无法在给定时间内完成 TCP 握手，您将获得连接超时。这样做的几个原因:

• 网络链接饱和。可以使用 sar -n DEV 1 并将 rxkB/s 和 txkB/s 列与您的链路最大吞吐量进行比较来诊断。
• 服务器 (Netty) 在给定的超时时间内未响应 accept() 调用。该线程可能被阻塞或 CPU 时间不足。您可以使用 strace -f -e trace=accept -p [java-pid] 找到哪些线程正在调用 accept()(因此完成 TCP 握手)。然后使用 pidstat/jstack 检查可能的原因。

您还可以使用 netstat -an | 找到已收到的连接打开(但未确认)请求数grep -c SYN_RECV

关于java - SelectorImpl 被阻塞，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18120634/