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

82

Considerando la siguiente línea de comando 

java -Xms128m -Xms256m myapp.jar

¿Qué configuración se aplicará a la memoria mínima de JVM ( Xmsopción): 128 mo 256 m?

java jvm jvm-arguments java-opts fabien7474
fuente
17
Sin error tipográfico en cuestión. Las opciones de Xms se utilizan dos veces a propósito. Esta es la esencia de la pregunta
fabien7474

Respuestas:

28

Depende de la JVM, quizás de la versión ... quizás incluso de cuántos clips tiene en su escritorio en ese momento. Puede que ni siquiera funcione. No hagas eso.

Si está fuera de su control por alguna razón, compílelo y ejecútelo de la misma manera que ejecutaría su jar. Pero tenga cuidado, confiar en el orden de las opciones es una muy mala 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());
    }
}
cHao
fuente
2
+1 - mejor cuente esos clips :-). En serio, no es ciencia espacial cambiar lo que sea que esté pasando esos argumentos ambiguos.
Stephen C
4
estado probando con diferente número de sujetapapeles. no puedo encontrar el cambio al primero
OganM
65

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

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

David Hergert
fuente
8
java -Xmx1G -XX:+PrintFlagsFinal -Xmx2G 2>/dev/null | grep MaxHeapSize, de esta manera es más fácil de deducir.
ryenus
40

IBM JVM trata la instancia más a la derecha de un argumento como el ganador. 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 al final y quieren que sea el ganador.

Trent Gray-Donald
fuente
21
+1 por responder la pregunta en lugar de pontificar.
JimN
De hecho: ibm.com/support/knowledgecenter/SSYKE2_7.0.0/…
Jorge Poveda
37

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

Marcin Owsiany
fuente
14
+1 por responder la pregunta en lugar de pontificar.
JimN
1
al igual que CSS, el último gana
ryenus
9

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

Vladimir Dyuzhev
fuente
8

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

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

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}

AdoptOpenJDK 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}
Kaan
fuente