Considering the following command line
java -Xms128m -Xms256m myapp.jar
Which settings will apply for JVM Minimum memory (Xms
option) : 128m or 256m ?
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.
来源:https://stackoverflow.com/questions/2740725/duplicated-java-runtime-options-what-is-the-order-of-preference