我在 Windows 下运行 Tomcat 6,使用捆绑的 Windows 服务运行器。我似乎有以下行为:
- 如果我的一个 web 应用程序写入 stdout(通过 System.out.println),那么此输出将逐字显示在标题为 stdout_xxx.log 的日志中。
- 如果 jvm 本身写入 stdout(就像启用 -XX:+PrintCompilation 时一样),那么此输出将显示在标题为 jakarta_service_xxx.log 的日志中。
此外,jakarta_service_xxx.log 不是 stdout 的直接转储;相反,似乎有什么东西在拦截 stdout 并通过 java 日志记录重定向它。因此,在 Tomcat 之外运行的 JVM 通常会打印
283 s java.lang.StringBuffer::length (5 bytes)
jakarta_service_xxx.log 中显示的内容如下:
[2010-01-15 17:07:15] [info] 283
[2010-01-15 17:07:15] [info] s
[2010-01-15 17:07:15] [info] java.lang.StringBuffer::
[2010-01-15 17:07:15] [info] l
[2010-01-15 17:07:15] [info] e
[2010-01-15 17:07:15] [info] n
[2010-01-15 17:07:15] [info] g
[2010-01-15 17:07:15] [info] t
[2010-01-15 17:07:15] [info] h
[2010-01-15 17:07:15] [info] (5 bytes)
您能解释一下为什么在这两种情况下 stdout 的处理方式不同吗?或者,有没有关于如何让 -XX:+PrintCompilation 的 JVM 输出显示在 stdout.log 中的提示,而不是像上面那样疯狂?
答案1
在不深入研究 Tomcat 内部的情况下,我认为顺序将是这样的。
启动 JVM 的新进程,传递“stdin”、“stdout”和“stderr”文件描述符。这些通常由调用 shell 设置并通过 fork/exec 系统调用传递给 JVM。(或 Windows 等效项...)但在这种情况下,在启动 JVM 之前,有一些包装器脚本或本机应用程序将“stdout”重定向到“jakarta_service_xxx.log”。
JVM 创建了一些内部日志系统(以本机代码实现),供 GC 和其他 JVM 服务用于 JVM 日志记录。这将使用“stdout”或“stderr”文件描述符。
JVM 创建 PrintStream(OutputStream)对象来包装“stdout”和“stderr”文件描述符并分别设置
java.lang.System.out
这些java.lang.System.err
对象。JVM调用Tomcat
main
方法来启动Tomcat。Tomcat 打开一个新的 FileOutputStream 到“stdout_xxx.log”并使用它
java.lang.System.setOut()
进行更新java.lang.System.out
。如果每个 webapp 都有不同的“stdout_xxx.log”文件,那么 Tomcat 很可能已经实现了一个巧妙的输出流代理,可以根据线程组或其他方式将输出解复用到不同的日志文件...
我怀疑 JVM 日志记录没有使用 java.util.Logging ... 或任何 Java 代码。它只是看起来就像这样。我这样说是因为我认为如果 JVM 试图在某些时候调用 Java 代码,它就会陷入困境;例如在 GC 的关键点。但我可能错了...
至于为什么会发生这种情况,我认为这是因为将来自 webapps 和 jvm / tomcat 核心的“System.out/err”输出分开通常是一个好主意。如果您愿意,可能有配置文件等允许您更改此设置...。
答案2
您通常希望将日志输出与 webapp 分开,并将其与容器内部消息(例如 JVM 诊断消息)分开。
除了支持各种日志框架之外,Tomcat 还捕获 System.out 和 System.err 并将它们重定向到适当的日志文件。
您应该能够在 Tomcat 的配置文件中配置确切的行为和格式(有关更多信息,请参阅 Serverfault...)