“Runtime.getRuntime().exec()” 性能不好？答案

【问题标题】：Does "Runtime.getRuntime().exec()" have a bad performance?“Runtime.getRuntime().exec()” 性能不好？
【发布时间】：2010-10-11 23:50:15
【问题描述】：

我想从我自己的 java 应用程序中执行一个 jar。（不可能将该 jar 导入库并将应用程序作为我自己的“启动器”的实例启动）。要从我自己的 java 应用程序中执行一个 jar...我正在使用下一行：

String [] cmd = new String [] {"java","-jar","myjar.jar"};
Process process = Runtime.getRuntime().exec(cmd, null, null);

这非常有效。我对此没有任何抱怨。

我的问题是：这是否与在命令行中通过“java -jar myjar.jar”执行该 jar 具有相同的性能？还是更糟？？如果更糟...关于我可以以相同的性能做到这一点的任何建议吗？

【问题讨论】：

标签： java performance jar runtime.exec

【解决方案1】：

性能基本相同，因为在两种情况下发生的事情基本相同。例如，在 UNIX/Linux 平台上：

当前进程已“分叉”。
新的子进程 'exec' 是 'java' 命令，传递指定的命令行参数。
子 JVM 启动 ...

可能存在次要性能差异。例如，父级处理子级标准输入/输出/错误流的方式可能不同。但通常你可以忘记这种事情。

[正如@Amadan 所说，使用类加载器在当前 JVM 中启动 Java 应用程序效率更高......因为它避免了 JVM 启动、公共代码的 JIT 编译等开销。但主要缺点（除了简单性之外）是“父”应用程序没有有效的方法来控制在同一JVM中运行的“子”应用程序。如果孩子陷入循环或资源管理通常马虎，父母也会受到影响。]

【讨论】：

这里要补充一点，至少在类 unix 系统上，进程的 fork() 会在将执行命令加载到内存之前复制整个进程。这在 HelloWorld 中使用时不会增加太多成本，但如果它是从 .war 或 .ear 文件中的应用程序服务器上下文完成的（其中应用程序服务器通常至少有数百个甚至一些数千兆字节的进程大小）

【解决方案2】：

这是一样的。

执行一个进程就是执行一个进程，无论是命令处理器执行它还是您的应用程序执行它。

【讨论】：

您能给我一个简单的解释或参考吗？谢谢！
我确认，它是相同的。这比通过ClassLoader 效率低但容易得多。

【解决方案3】：

无论如何都是一样的。使用新的 api ProcessBuilder，它可以更好地指定参数..

【讨论】：