Opciones de tiempo de ejecución de Java duplicadas: ¿cuál es el orden de preferencia?

Teniendo en cuenta la siguiente línea de comando

java -Xms128m -Xms256m myapp.jar

Qué configuración se aplicará a la memoria mínima de JVM (Xms opción) : 128m o 256m ?

Como siempre, verifique la implementación específica de su JVM local, pero aquí hay una forma rápida de verificar desde la línea de comando sin tener que codificar.

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

Así que verá en este caso, la segunda instancia del argumento (2G) es lo que tiene prioridad (al menos en 1.8) y esa ha sido mi experiencia con la mayoría de las otras versiones modernas también.

IBM JVM trata la instancia más a la derecha de un argumento como ganadora. No puedo hablar con HotSpot, etc.

Hacemos esto porque a menudo hay líneas de comando profundamente anidadas de archivos por lotes donde las personas solo pueden agregar hasta el final y quieren que sea el ganador.

FTR, OpenJDK 1.7 también parece tomar el valor más a la derecha, al menos para -Xms.

¿Qué ajustes se aplicarán a la memoria mínima de JVM?

En las diversas versiones de Java enumeradas a continuación, el “ganador” es el valor más a la derecha en la lista de argumentos. Como otros han señalado, no es una buena idea confiar en esto, pero tal vez sea información útil para compartir de todos modos.

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

~ $ 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

~ $ 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}

Adoptar 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

~ $ 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}

Apuesto a que es el segundo. Los argumentos generalmente se procesan en el orden:

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

Pero si estuviera escribiendo un analizador de argumentos de Java, me quejaría de los argumentos en conflicto.

Mis experimentos muestran que toma el valor máximo de xmx.

Así que si pasas -xmx4g -xmx1g tomará 4ty si pasas -xmx1g -xmx4g todavía tomará 4g.