Java 为什么bash-c；ulimit-Sn“；从JVM调用时是否有不同的输出？

命令是“ulimit-Sn”，Java代码如下所示调用它

Process process = Runtime.getRuntime().exec(new String[] { "bash", "-c", cmd });
process.waitFor();
BufferedReader outputReader = new BufferedReader(new InputStreamReader(process.getInputStream()));

String line = "";

while ((line = outputReader.readLine()) != null) {
    output.append(line + "\n");
}

System.out.println(output.toString());

我在shell中运行命令，结果是1024，但在同一个shell中运行java代码，结果是4096。为什么？

不同的进程配置不同的ulimit是完全正常的；这与java或bash无关。 您要求对为您的进程配置的打开文件描述符的最大数量进行软限制

再次说明：为您的流程配置了。不同的进程可以配置不同的ulimit

例如，如果其中一个是从systemd服务启动的，

LimitNOFILE=4096

将提供一个新值

如果其中一个是从调用

ulimit

命令的脚本启动的，则可能会提供一个新值

如果其中一个是由用户帐户、服务或配置了PAM规则的登录机制启动的，那么也可以提供新的值

---

---

顺便说一下，在Linux上，您可以通过读取文件

/proc/self/limits

以完全独立于语言的方式提取此值。通过在不同进程的PID中替换

self

，您可以在不同进程之间阅读和比较此信息。

您是否阅读了

ulimit

的文档？这与Java无关，与返回不同输出的命令有关。顺便说一句，您应该在调用

waitFor（）

之前使用进程的输出。但是我运行的两种方法在同一个shell中。首先，我直接运行'ulimit-Sn'，然后运行java代码。因为在同一个shell中，我认为环境（等PAM）是相同的。如果限制在同一个shell中可以不同，那么它在哪里以及如何决定？它是一个每个进程的标志——任何进程都可以更改它。您的shell启动一个JVM->这是一个新进程，如果它选择更改自己的ulimit及其子进程的ulimit，那么它就有能力。该JVM启动第二个shell->该shell继承JVM设置的ulimit。如果要确认这一点，可以找到JVM的PID并检查

/proc/${JVM\u PID}/limits

。