Реальные различия между "java-сервером"и" java-клиентом"?

наиболее заметной непосредственной разницей в более старых версиях Java была бы память, выделенная для -client в противоположность -server приложение. Например, в моей системе Linux я получаю:

$ java -XX:+PrintFlagsFinal -version 2>&1 | grep -i -E 'heapsize|permsize|version'
uintx AdaptivePermSizeWeight               = 20               {product}
uintx ErgoHeapSizeLimit                    = 0                {product}
uintx InitialHeapSize                     := 66328448         {product}
uintx LargePageHeapSizeThreshold           = 134217728        {product}
uintx MaxHeapSize                         := 1063256064       {product}
uintx MaxPermSize                          = 67108864         {pd product}
uintx PermSize                             = 16777216         {pd product}
java version "1.6.0_24"

как это по умолчанию:-server, но с Я:

$ java -client -XX:+PrintFlagsFinal -version 2>&1 | grep -i -E 'heapsize|permsize|version'
uintx AdaptivePermSizeWeight               = 20               {product}
uintx ErgoHeapSizeLimit                    = 0                {product}
uintx InitialHeapSize                     := 16777216         {product}
uintx LargePageHeapSizeThreshold           = 134217728        {product}
uintx MaxHeapSize                         := 268435456        {product}
uintx MaxPermSize                          = 67108864         {pd product}
uintx PermSize                             = 12582912         {pd product}
java version "1.6.0_24"

так и с -server большинство ограничений памяти и начальных выделений намного выше для этого java версия.

эти значения могут меняться для разных однако комбинации архитектуры, операционной системы и версии jvm. Последние версии jvm удалили флаги и повторно переместили многие различия между сервером и клиентом.

помните, что вы можете увидеть все детали работающей jvm используя jvisualvm. Это полезно, если у вас есть пользователи, которые или модули, которые устанавливают JAVA_OPTS или использовать скрипты, которые изменяют параметры командной строки. Это также позволит вам контролировать в реальном времени кучу и permgen использование пространства наряду с большим количеством других характеристик.

одно отличие, которое я только что заметил, заключается в том, что в режиме "клиент" кажется, что JVM фактически возвращает некоторую неиспользуемую память обратно в операционную систему, тогда как в режиме "сервер", как только JVM захватывает память, он не вернет ее. Вот как это выглядит на Solaris с Java6 в любом случае (используя prstat-Z, чтобы увидеть объем памяти, выделенной для процесса).

системы-клиент и-сервер - это разные двоичные файлы. Они по существу являются двумя разными компиляторами (JITs), взаимодействующими с одной и той же системой выполнения. Клиентская система оптимальна для приложений, которым требуется быстрое время запуска или небольшие следы, серверная система оптимальна для приложений, где общая производительность является наиболее важной. В целом клиентская система лучше подходит для интерактивных приложений, таких как графические интерфейсы

мы запускаем следующий код с обоими переключателями:

package com.blogspot.sdoulger;

public class LoopTest {
    public LoopTest() {
        super();
    }

    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        spendTime();
        long end = System.currentTimeMillis();
        System.out.println("Time spent: "+ (end-start));

        LoopTest loopTest = new LoopTest();
    }

    private static void spendTime() {
        for (int i =500000000;i>0;i--) {
        }
    }
}

Примечание: код компилируется только один раз! Классы одинаковы в обоих заездах!

С клиентом:
Ява.exe-клиент-classpath C:\mywork\classes com.- нет.сдулгер.LoopTest
Потраченное время: 766

With-server:
Ява.EXE-файл -сервер -классов C:\mywork\classes com.- нет.сдулгер.LoopTest
Затраченное время: 0

Кажется, что чем агрессивнее оптимизация серверной системы, тем больше петля удаляется, так как она понимает, что не выполняет никаких действий!

ссылка

онлайн-документация Oracle предоставляет некоторую информацию для Java SE 7.

на java-Java application launcher страница для Windows, the -client параметр игнорируется в 64-разрядном JDK:

выберите виртуальную машину клиента точки доступа Java. 64-разрядный JDK в настоящее время игнорирует этот параметр и вместо этого использует виртуальную машину Java HotSpot Server.

однако (чтобы сделать вещи интересные), под -server говорится:

выберите виртуальную машину Java HotSpot Server. На 64-разрядном совместимом jdk поддерживается только виртуальная машина Java HotSpot Server, поэтому параметр-server неявен. Это может быть изменено в будущем выпуске.

The Обнаружение Машин Серверного Класса страница содержит информацию о том, какая виртуальная машина выбрана ОС и архитектурой.

Я не знаю, насколько это относится к JDK 6.

IIRC сервер VM делает больше оптимизаций hotspot при запуске, поэтому он работает быстрее, но занимает немного больше времени для запуска и использует больше памяти. Клиентская виртуальная машина откладывает большую часть оптимизации, чтобы ускорить запуск.

правка, чтобы добавить: вот некоторая информация от Солнца, это не очень конкретно, но даст вам некоторые идеи.

из параллелизма Goetz-Java на практике:

1. совет по отладке: для серверных приложений всегда указывайте параметр командной строки-server JVM при вызове JVM,даже для разработка и тестирование. Сервер JVM выполняет дополнительную оптимизацию чем клиент JVM, например, подъем переменных из цикла, которые являются не изменяется в цикле; код, который может работать в среда разработки (клиент JVM) может сломаться в развертывании среды (JVM сервера). Например, если бы мы "забыли" объявить переменная Sleep as volatile в листинге 3.4,сервер JVM может поднимите тест из петли (превратив его в бесконечную петлю), но клиент JVM не будет. Бесконечный цикл, который появляется в разработка гораздо дешевле, чем тот, который появляется только в производство.

листинг 3.4. Считая овец.

volatile boolean asleep; ... while (!asleep) countSomeSheep();

мой акцент. YMMV

IIRC, он включает в себя стратегии сбора мусора. Теория заключается в том, что клиент и сервер будут отличаться с точки зрения короткоживущих объектов, что важно для современных алгоритмов GC.

вот ссылка в режиме сервера. Увы, они не упоминают клиентский режим.

вот очень тщательная ссылка на GC в целом; это более Основная статья. Не уверен, что любой адрес-сервер vs-клиент, но это актуально материал.

в No Fluff Just Stuff, как Кен Сипе, так и Гленн Ванденбург делают отличные разговоры о таких вещах.

Я не заметил никакой разницы во времени запуска между 2, но зафиксировал очень минимальное улучшение производительности приложения с помощью "-server" (сервер Solaris, все используют солнечные лучи для запуска приложения). Это было под 1.5.

в последний раз, когда я смотрел на это (и, по общему признанию, это было некоторое время назад), самая большая разница, которую я заметил, была в сборке мусора.

IIRC:

• виртуальная машина кучи сервера имеет другое число поколений, чем клиентская виртуальная машина, и другой алгоритм сборки мусора. это не может быть правдой больше
• сервер VM будет выделять память и не выпускать ее в ОС
• сервер VM будет использовать более сложные алгоритмы оптимизации, и, следовательно, имеют большие требования к времени и памяти для оптимизации

если вы можете сравнить две виртуальные машины java, один клиент, один сервер с помощью jvisualvm инструмент, вы должны увидеть разницу в частоте и эффекте сборки мусора, а также в количестве поколений.

У меня была пара скриншотов, которые показали разницу очень хорошо, но я не могу воспроизвести, поскольку у меня есть 64-битный JVM, который реализует только виртуальную машину сервера. (И я не могу беспокоиться о том, чтобы загрузить и пререкаться с 32-битной версией в моей системе.)

похоже, это больше не так, попробовав запустить некоторый код в windows как с серверными, так и с клиентскими виртуальными машинами, я, похоже, получаю одну и ту же модель поколения для обоих...

при выполнении миграции с версии 1.4 на 1.7 ("1.7.0_55").То, что мы наблюдали здесь, нет таких различий в значениях по умолчанию, назначенных параметрам heapsize|permsize|ThreadStackSize в режиме клиента и сервера.

кстати, (http://www.oracle.com/technetwork/java/ergo5-140223.html). это фрагмент, взятый из ссылки выше.

initial heap size of 1/64 of physical memory up to 1Gbyte
maximum heap size of ¼ of physical memory up to 1Gbyte

ThreadStackSize выше в 1.7, проходя через открытый форум JDK, есть обсуждения, которые заявили размер кадра несколько выше в версии 1.7. Считается, что реальную разницу можно было бы измерить во время выполнения на основе вашего поведения вашего приложения