Учитывая следующую командную строку
java -Xms128m -Xms256m myapp.jar
Какие настройки будут применяться для JVM. Минимальный объем памяти ( Xms
опция): 128 или 256 МБ?
Учитывая следующую командную строку
java -Xms128m -Xms256m myapp.jar
Какие настройки будут применяться для JVM. Минимальный объем памяти ( Xms
опция): 128 или 256 МБ?
Ответы:
Зависит от JVM, возможно, от версии ... возможно, даже от того, сколько скрепок у вас сейчас на столе. Это может даже не сработать. Не делай этого.
Если по какой-то причине это выходит из-под вашего контроля, скомпилируйте и запустите его так же, как и свой 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());
}
}
Как всегда, проверьте конкретную реализацию вашей локальной 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}
В этом случае вы увидите, что второй вариант аргумента (2G) имеет приоритет (по крайней мере, в 1.8), и это был мой опыт работы с большинством других современных версий.
java -Xmx1G -XX:+PrintFlagsFinal -Xmx2G 2>/dev/null | grep MaxHeapSize
, таким образом легче вывести.
IBM JVM рассматривает крайний правый экземпляр аргумента как победитель. Я не могу разговаривать с HotSpot и т. Д.
Мы делаем это, потому что часто есть глубоко вложенные командные строки из командных файлов, где люди могут добавлять только в конец и хотят сделать это победителем.
Держу пари, это второй. Аргументы обычно обрабатываются в следующем порядке:
for( int i=0; i<argc; i++ ) {
process_argument(argv[i]);
}
Но если бы я писал парсер аргументов java, я бы пожаловался на конфликтующие аргументы.
Какие настройки будут применяться для минимальной памяти JVM?
В различных версиях Java, перечисленных ниже, «победитель» - это крайнее правое значение в списке аргументов. Как отмечали другие, полагаться на это - не лучшая идея, но, возможно, это полезная информация, которой стоит поделиться.
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-е.
~ $ 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}