不要在服务器端代码中使用 System.out.println

Question

我听说使用 System.out.println 进行日志记录是一种非常糟糕的做法，这可能会迫使服务器失败。

我不使用这种方法，但我很想知道为什么 System.out.println 在后端代码中使用时会产生如此垃圾的东西。

Answer 1

System.out.println 是一个 IO 操作，因此非常耗时。
在代码中使用它的问题是，您的程序将等待 println 完成。对于小网站来说这可能不是问题，但一旦你获得负载或多次迭代，你就会感到痛苦。

更好的方法是使用日志框架。
它们使用消息队列，并且仅在没有其他输出发生时才进行写入。

另一个好处是您可以为不同的目的配置单独的日志文件。
您的运营团队一定会喜欢您的。

在此处阅读更多信息：

• http://logging.apache.org/ log4j/1.2/manual.html
• 记录器与 System.out.println

Answer 2

查看 Adam Biens Java 杂志 11 月/12 月版中有关压力测试 JEE6 应用程序的文章 - 它是免费在线，您只需订阅即可。

他在第 43 页上展示了，当插入一个带有固定字符串的 System.out.println 时，每秒处理 1700 个事务的服务器应用程序会下降到仅 800 个。

Answer 3

这是一种不好的做法，因为当您的应用程序投入生产时，您无法将应用程序日志与服务器日志分开。

产品团队希望将应用程序生成的日志与应用程序服务器（tomcat、websphere 等）生成的日志分开：他们希望能够以不同于应用程序本身的方式监视应用程序服务器。

此外，使用 System.out，您无法定义日志级别：在生产中，您不想打印调试信息。

Answer 4

它被认为是不好的，因为 System.out.println(); 会占用更多的 cpu，因此输出变慢意味着会损害性能。 （实际上每个I/O操作都会吃cpu）。

Answer 5

原因不是服务器可能失败，而是可能很难在服务器上找到此类输出。您应该始终使用某种具有定义的行为和输出文件的日志记录框架。

Answer 6

其一，让多个请求访问您的服务器并在 System.out 上打印日志并不是一个好的做法。

1. 所有日志都会打印在屏幕上（文件描述符）。无法向后滚动并阅读日志。
2. System.out 未同步。必须有并发管理来通过System.out管理打印。
3. 您无法通过System.out确定日志级别。您无法即时分离日志级别以分离输出。

我希望这有帮助。

Answer 7

1. 程序将等待，直到 println 完成。
   记录器使用消息队列，并且仅在没有其他输出发生时才进行写入。
2. System.out.println (SOP) 不是线程安全的（即异步）
   记录器是线程安全的（即同步）
3. 记录器是高度可配置的
   a. 格式化，限制记录器可实现的日志内容
   b. 多目标日志记录 – 文件、控制台、DB
4. SOP 将日志写入服务器日志文件。
   我们需要将应用程序日志与服务器日志分开，因为这可能会导致服务器故障
5. 服务器应用程序每秒处理 1700 个事务，当在每个事务中插入带有修复字符串的单个 SOP 时，每秒处理的事务数会下降到仅 800 个

Answer 8

使用标准输出是不好的做法。但是，如果您有一个库或使用 System.out 和 System.err 的代码，您可以编写自己的 PrintStream 来记录线程名称以及 info() 和 error() 文本。完成此操作后，您可能会更轻松地使用 System.out，因为它将写入日志，例如 log4j。

理想情况下，您将直接使用正确的日志，特别是用于调试级别日志记录。恕我直言，只要您不使用内置的 System.out/err，它就没有那么重要！ （诚​​然，这是一个很大的假设）

无论您使用重定向到文件的 System.out 还是使用 log4j 或 Java Logger 写入文件，性能几乎完全相同。

Answer 9

另一个原因是 System.out 和 err 是 PrintStream，它们消耗所有底层 IOException。请参阅 PrintStreams 的以下方法：

/**
 * Writes the specified byte to this stream.  If the byte is a newline and
 * automatic flushing is enabled then the <code>flush</code> method will be
 * invoked.
 *
 * <p> Note that the byte is written as given; to write a character that
 * will be translated according to the platform's default character
 * encoding, use the <code>print(char)</code> or <code>println(char)</code>
 * methods.
 *
 * @param  b  The byte to be written
 * @see #print(char)
 * @see #println(char)
 */
public void write(int b) {
    try {
        synchronized (this) {
            ensureOpen();
            out.write(b);
            if ((b == '\n') && autoFlush)
                out.flush();
        }
    }
    catch (InterruptedIOException x) {
        Thread.currentThread().interrupt();
    }
    catch (IOException x) {
        trouble = true;
    }
}

/**
 * Flushes the stream and checks its error state. The internal error state
 * is set to <code>true</code> when the underlying output stream throws an
 * <code>IOException</code> other than <code>InterruptedIOException</code>,
 * and when the <code>setError</code> method is invoked.  If an operation
 * on the underlying output stream throws an
 * <code>InterruptedIOException</code>, then the <code>PrintStream</code>
 * converts the exception back into an interrupt by doing:
 * <pre>
 *     Thread.currentThread().interrupt();
 * </pre>
 * or the equivalent.
 *
 * @return <code>true</code> if and only if this stream has encountered an
 *         <code>IOException</code> other than
 *         <code>InterruptedIOException</code>, or the
 *         <code>setError</code> method has been invoked
 */
public boolean checkError() {
    if (out != null)
        flush();
    if (out instanceof java.io.PrintStream) {
        PrintStream ps = (PrintStream) out;
        return ps.checkError();
    }
    return trouble;
}

因此，始终会消耗来自底层流的 IOException，并且通常人们不会在系统输出上调用 checkError，因此他们甚至不知道发生了某些事情。