重复的 Java 运行时选项：优先顺序是什么？

Duplicated Java runtime options : what is the order of preference?

提问by fabien7474

Considering the following command line

考虑以下命令行

java -Xms128m -Xms256m myapp.jar

Which settings will apply for JVM Minimum memory (Xmsoption) : 128m or 256m ?

哪些设置将适用于 JVM 最小内存（Xms选项）：128m 或 256m？

采纳答案by cHao

Depends on the JVM, perhaps the version...perhaps even how many paper clips you have on your desk at the time. It might not even work. Don't do that.

取决于 JVM，也许是版本......也许甚至你当时办公桌上有多少回形针。它甚至可能不起作用。不要那样做。

If it's out of your control for some reason, compile and run this the same way you'd run your jar. But be warned, relying on the order of the options is a really bad idea.

如果由于某种原因它超出您的控制范围，请按照与运行 jar 相同的方式编译和运行它。但请注意，依赖选项的顺序是一个非常糟糕的主意。

public class TotalMemory
{
    public static void main(String[] args)
    {
         System.out.println("Total Memory: "+Runtime.getRuntime().totalMemory());
         System.out.println("Free Memory: "+Runtime.getRuntime().freeMemory());
    }
}

回答by Vladimir Dyuzhev

I bet it's the second one. Arguments are usually processed in the order:

我敢打赌这是第二个。参数通常按以下顺序处理：

for( int i=0; i<argc; i++ ) {
  process_argument(argv[i]);
}

But if I were writing java argument parser, I'd complain on conflicting arguments.

但是如果我正在编写 java 参数解析器，我会抱怨参数冲突。

回答by Trent Gray-Donald

The IBM JVM treats the rightmost instance of an argument as the winner. I can't speak to HotSpot, etc..

IBM JVM 将参数的最右侧实例视为获胜者。我无法与 HotSpot 等通话。

We do this as there are often deeply nested command lines from batch files where people can only add to the end, and want to make that the winner.

我们这样做是因为批处理文件中经常有深度嵌套的命令行，人们只能在其中添加到最后，并希望使其成为赢家。

回答by Marcin Owsiany

FTR, OpenJDK 1.7 also seems to take the rightmost value, at least for -Xms.

FTR，OpenJDK 1.7 似乎也采用了最右边的值，至少对于 -Xms。

回答by David Hergert

As always, check your local JVM's specific implementation but here is a quick way to check from the command line without having to code.

与往常一样，检查本地 JVM 的特定实现，但这里是一种无需编码即可从命令行进行检查的快速方法。

> java -version; java -Xmx1G -XX:+PrintFlagsFinal -Xmx2G 2>/dev/null | grep MaxHeapSize

java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
uintx MaxHeapSize         := 2147483648        {product}

So you'll see in this case, the second instance of the argument (2G) is what takes precedence (at least in 1.8) and that has been my experience with most other modern versions as well.

所以你会在这种情况下看到，参数 (2G) 的第二个实例优先（至少在 1.8 中），这也是我对大多数其他现代版本的经验。

回答by kaan

Which settings will apply for JVM Minimum memory?

哪些设置将适用于 JVM 最小内存？

In the various versions of Java listed below, the "winner" is the right-most value in the argument list. As others have pointed out, it is not a good idea to rely on this, but perhaps this is useful information to share nonetheless.

在下面列出的各种 Java 版本中，“赢家”是参数列表中最右边的值。正如其他人所指出的那样，依赖于此并不是一个好主意，但也许这是值得分享的有用信息。

Java 1.8.0_172

Java 1.8.0_172

~ $ java8
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)
~ $ java -Xmx1024m -Xmx4024m -XX:+PrintFlagsFinal Test 2>/dev/null | grep MaxHeapSize
    uintx MaxHeapSize                              := 4219469824                          {product}

Java 11.0.3

Java 11.0.3

~ $ java11
java version "11.0.3" 2019-04-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode)
~ $ java -Xmx1024m -Xmx4024m -XX:+PrintFlagsFinal Test 2>/dev/null | grep MaxHeapSize
   size_t MaxHeapSize                              = 4219469824                                {product} {command line}

OpenJDK 12.0.1

OpenJDK 12.0.1

~ $ java12
openjdk version "12.0.1" 2019-04-16
OpenJDK Runtime Environment (build 12.0.1+12)
OpenJDK 64-Bit Server VM (build 12.0.1+12, mixed mode, sharing)
~ $ java -Xmx1024m -Xmx4024m -XX:+PrintFlagsFinal Test 2>/dev/null | grep MaxHeapSize
   size_t MaxHeapSize                              = 4219469824                                {product} {command line}

AdoptOpenJDK 12.0.1

采用OpenJDK 12.0.1

~ $ java12a
openjdk version "12.0.1" 2019-04-16
OpenJDK Runtime Environment AdoptOpenJDK (build 12.0.1+12)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 12.0.1+12, mixed mode, sharing)
~ $ java -Xmx1024m -Xmx4024m -XX:+PrintFlagsFinal Test 2>/dev/null | grep MaxHeapSize
   size_t MaxHeapSize                              = 4219469824                                {product} {command line}

OpenJDK 13-ea

OpenJDK 13-ea

~ $ java13
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+22)
OpenJDK 64-Bit Server VM (build 13-ea+22, mixed mode, sharing)
~ $ java -Xmx1024m -Xmx4024m -XX:+PrintFlagsFinal Test 2>/dev/null | grep MaxHeapSize
   size_t MaxHeapSize                              = 4219469824                                {product} {command line}