【问题标题】:Java is using 100% of CPU using socketsJava 正在使用 100% 的 CPU 使用套接字
【发布时间】:2013-10-18 08:31:31
【问题描述】:

我有一个 Java 应用程序在 Linux 机器上的 tomcat 上运行。这个应用程序像一个套接字服务器一样工作,其中连接了大约 15 个设备。似乎当设备发送一条大消息时,cpu 会增长到 100% 的使用率。问题是如果我取消部署应用程序,java 仍然拥有 99% 的 CPU。该应用程序有两个部分:

套接字服务器:

    public void iniciarSocket() {

    Runnable serverTask = new Runnable() {
        @Override
        public void run() {
            try {

                serverSocket = new ServerSocket(PORT);

                System.out.println("Waiting a connection");

                while (true) {
                    Socket socket = null;

                    try {
                        socket = serverSocket.accept();

                        System.out.println("Client connected");
                    } catch (Exception e) {
                        System.out.println("Error: " + e.getMessage());
                    }
                    new SocketThread(socket).start();
                }

            } catch (Exception e) {
                System.out.println("Error: " + e.getMessage());
            }
        }
    };
    Thread serverThread = new Thread(serverTask);
    serverThread.start();
}

每个套接字线程,与每个设备连接:

    public void run() {
    try {

        //Output channel
        DataOutputStream salida;
        salida = new DataOutputStream(socket.getOutputStream());

        System.out.println("Client connected.... ");

        byte[] buff = new byte[1024];
        int bytesLeidos = 0;
        socket.setSoTimeout(300000);
        System.out.println("Timeout: " + socket.getSoTimeout());

        while((bytesLeidos = socket.getInputStream().read(buff, 0, buff.length)) > -1) {

            System.out.println("Bytes leidos: " + bytesLeidos);

            if ((bytesLeidos == 70) && (Protocolo.isStatusMessage(buff))) {
                Protocolo.decode(buff, salida);
            } else {

                int offset = 0;

                while (offset < bytesLeidos) {

                    while ((offset + 70 <= bytesLeidos) &&(!Protocolo.isStatusMessageWithOffset(buff, offset))) {
                        offset++;
                    }

                    if ((offset + 70 <= bytesLeidos) &&(Protocolo.isStatusMessageWithOffset(buff, offset))) {
                        Protocolo.decodeWithOffset(buff, offset, salida);
                        offset += 70;
                    }
                }
            }
        }
    } catch (Exception e) {
        System.out.println();
    } finally {
        System.out.println("Communication ended");
        try {
            socket.close();
        } catch (Exception e) {
            System.out.println("Socket not closed");
        }
    }
}

我不明白发生了什么,我正在处理很多事情,但我无法解决问题。

【问题讨论】:

  • 如果您不增加offset.,您可能会陷入while (offset &lt; bytesLeidos) 循环中
  • while (true) { ?,见stackoverflow.com/questions/580419/…,在这种情况下还要考虑添加更多日志。
  • 如果您的 ServerSocket.accept() 调用失败,SocketThread 可以传递一个空值。此外,更一般地,您应该只捕获您期望的异常类型,例如 SocketException,而不是捕获 Exception。
  • "while (true) {" 你的“serverThread”永远不会死!
  • 是的,serverThread 永远不会死。这是必要的,因为服务器总是在等待新设备。但这并不是一个忙碌的等待。这个线程只有在我部署应用程序时才会停止。

标签: java sockets tomcat


【解决方案1】:

看来问题解决了。 EJP 是对的,如果消息不是 70 的倍数,则循环永远不会结束。我只需要更改 socketThread。

            while((bytesLeidos = socket.getInputStream().read(buff, 0, buff.length)) > -1) {

            System.out.println("Bytes leidos: " + bytesLeidos);

            if ((bytesLeidos == 70) && (Protocolo.isStatusMessage(buff))) {
                Protocolo.decode(buff, salida);
            } else {


                int offset = 0;

                // Code changed
                while (offset < bytesLeidos) {

                    if (Protocolo.isStatusMessageWithOffset(buff, offset)) {
                        // decodificar
                        Protocolo.decodeWithOffset(buff, offset, salida);
                        offset += 70;
                    } else {
                        offset++;
                    }
                }
                // End code changed
            }
        }

非常感谢。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-03-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-02-10
    相关资源
    最近更新 更多