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

て烟熏妆下的殇ゞ 提交于 2019-11-27 13:50:32

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.

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.

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());
    }
}

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.

> 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.

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

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.

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

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!