Реальні відмінності між "Java-сервер" та "java-кліент"?

Чи є реальна практична різниця між "java -server" та "java -client"?

Все, що я можу знайти на сайті Sun, - неясне

"-сервер починається повільніше, але повинен працювати швидше".

Які реальні відмінності? (Зараз використовується JDK 1.6.0_07.)

Це дійсно пов'язано з HotSpot та значеннями за замовчуванням параметри ( Java HotSpot VM Options ), які відрізняються між клієнтською та серверною конфігурацією.

З глави 2 довідки ( архітектура двигуна Java HotSpot Performance Engine ):

JDK включає два варіанти VM - пропозицію на стороні клієнта та VM, налаштовану на серверні програми. Ці два рішення мають спільну базу коду середовища виконання Java HotSpot, але використовують різні компілятори, які підходять до чітко унікальних характеристик продуктивності клієнтів та серверів. Ці відмінності включають політику складання вкладених політик та купують за замовчуванням.

Незважаючи на те, що сервер і клієнтські віртуальні машини схожі, сервер VM був спеціально налаштований на максимальну максимальну швидкість роботи. Він призначений для виконання довгострокових серверних додатків, яким потрібна максимально швидка швидкість роботи більше, ніж швидкий час запуску або менший слід пам’яті часу виконання.

Клієнтський компілятор VM служить оновленням як для класичного VM, так і для щойно вчасно (JIT) компіляторів, використовуваних у попередніх версіях JDK. Клієнт VM пропонує покращену продуктивність роботи додатків та аплетів. Java HotSpot Client VM була спеціально налаштована на скорочення часу запуску програми та сліду пам’яті, що робить його особливо підходящим для клієнтського середовища. Взагалі клієнтська система краща для графічних інтерфейсів.

Тож реальна різниця також на рівні компілятора:

Клієнт VM-компілятор не намагається виконати багато складніших оптимізацій, виконаних компілятором у серверному віртуальному комп'ютері, але в обмін на це потрібно менше часу для аналізу та складання фрагмента коду. Це означає, що клієнтський комп'ютерний комп'ютер може запускатися швидше і вимагає меншої площі пам'яті.

Сервер VM містить вдосконалений адаптивний компілятор, який підтримує безліч однакових типів оптимізацій, що виконуються за допомогою оптимізації компіляторів C ++, а також деякі оптимізації, які неможливо здійснити традиційними компіляторами, наприклад, агресивне вбудовування через виклики віртуального методу. Це конкурентна перевага та ефективність роботи перед статичними компіляторами. Технологія адаптивної оптимізації дуже гнучка у своєму підході і, як правило, перевершує навіть сучасні методи статичного аналізу та компіляції.

Примітка. Випуск оновлення jdk6 10 (див. Примітки до випуску оновлень: Зміни в 1.6.0_10 ) намагався покращити час запуску, але з іншої причини, ніж параметри точки гарячої точки, упаковуючись по-різному зі значно меншим ядром.

Г. Демецький в коментарях вказує, що в 64-бітних версіях JDK цей -clientваріант ігнорується протягом багатьох років.
Див. Команду Windowsjava :

-client

Вибирає програму VM клієнта Java HotSpot.
На даний момент 64-розрядний JDK ігнорує цю опцію і замість цього використовує віртуальну машину Java Hotspot Server .

Найбільш помітною негайною відмінністю у старих версіях Java буде пам'ять, виділена a, -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, але з -clientможливістю отримати:

$ 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або використовують сценарії, які змінюють параметри командного рядка. Це також дозволить вам відстежувати в реальному часі використання купі та пермгенського простору, а також безліч інших статистичних даних.

системи -client і -server - це різні бінарні файли. Вони по суті є двома різними компіляторами (JIT), що поєднуються в одній і тій же системі виконання. Клієнтська система оптимальна для додатків, які потребують швидкого часу запуску або невеликих слідів, серверна система є оптимальною для додатків, де загальна продуктивність є найважливішою. Взагалі клієнтська система краще підходить для інтерактивних додатків, таких як GUI

Ми виконуємо наступний код обома перемикачами:

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

Примітка: Код складено лише один раз! Заняття однакові в обох запусках!

З -client:
java.exe -client -classpath C: \ моя робота \ класи com.blogspot.sdoulger.LoopTest
витрачений час: 766

З -server:
java.exe -server -classpath C: \ моя робота \ класи com.blogspot.sdoulger.LoopTest Проведено
час: 0

Здається, що при більш агресивній оптимізації серверної системи зніміть цикл, оскільки він розуміє, що вона не виконує жодної дії!

Довідково

Однією з різниць, яку я щойно помітив, є те, що в режимі «клієнт», схоже, JVM фактично повертає деяку невикористану пам’ять назад в операційну систему, тоді як у режимі «сервер», як тільки JVM захопить пам'ять, він не надасть її назад. Ось як це виглядає на Solaris з Java6 у будь-якому випадку (використовуючи prstat -Zдля перегляду обсягу пам'яті, виділеної на процес).

Інтернет-документація Oracle надає деяку інформацію для Java SE 7.

На Java - сторінці запуску додатків Java для Windows, -clientв 64-бітному JDK параметр ігнорується:

Виберіть програму VM клієнта Java HotSpot. На даний момент 64-розрядний jdk ігнорує цю опцію і замість цього використовує сервер VM Java HotSpot.

Однак (щоб зробити речі цікавими), під -serverним зазначено:

Виберіть програму VM-сервера Java HotSpot. На 64-розрядному jdk підтримується лише сервер VM Java HotSpot Server, тому опція -server неявна. Це може змінитися в майбутньому випуску.

На сторінці машинного виявлення серверного класу наведена інформація про те, який VM обраний ОС та архітектурою.

Я не знаю, наскільки це стосується JDK 6.

Від Goetz - Конкурс Java на практиці:

6. Порада щодо налагодження. Для серверних програм обов’язково завжди вказуйте -serverперемикач командного рядка JVM при виклику JVM, навіть для розробки та тестування . Сервер JVM здійснює більшу оптимізацію, ніж клієнтський JVM, наприклад підняття змінних із циклу, які не модифіковані в циклі; код, який, можливо, працює в середовищі розробки (клієнт JVM), може порушитися в середовищі розгортання (сервер JVM). Наприклад, якби ми «забули» оголосити змінну, що спить, як мінливу у Лістингу 3.4, сервер JVM міг би підняти тест із циклу (перетворивши його у нескінченний цикл), але клієнтський JVM цього не зробив . Нескінченний цикл, який виявляється в розвитку, набагато дешевший, ніж той, який з'являється лише у виробництві.

Лістинг 3.4. Підрахунок овець.

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

Мій акцент. YMMV

IIRC сервер VM робить більше оптимізацій гарячої точки при запуску, тому він працює швидше, але запускає трохи більше часу і використовує більше пам'яті. Клієнтська вітрина відкладає більшу частину оптимізації для швидшого запуску.

Редагувати, щоб додати: Ось інформація від Sun, вона не дуже конкретна, але дасть вам кілька ідей.

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

Ось посилання на серверний режим. На жаль, вони не згадують клієнтський режим.

Ось дуже ґрунтовне посилання на GC загалом; це більш основна стаття . Не впевнений, чи адреса -server vs -client, але це відповідний матеріал.

Із No Fluff Just Stuff, і Кен Сіпе, і Гленн Ванденбург великі переговори з цього приводу.

Я не помічав різниці у часі запуску між двома, але зафіксував дуже мінімальне поліпшення продуктивності програми за допомогою "-server" (сервер Solaris, всі, хто використовує SunRays для запуску програми). Це було менше 1,5.

Минулого разу я придивився до цього (і, правда, це був час назад), найбільша різниця, яку я помітив, була у збиранні сміття.

IIRC:

• Віртуальний сервер купі VM має різну кількість поколінь, ніж Client VM, та інший алгоритм збору сміття. Це може бути вже неправдою
• Сервер VM буде виділяти пам'ять, а не випускати її в ОС
• Сервер VM використовуватиме більш складні алгоритми оптимізації, а отже, і більші вимоги до часу та пам'яті для оптимізації

Якщо ви можете порівняти два відеомагнітофони java, один клієнт, один сервер за допомогою інструменту jvisualvm , ви повинні побачити різницю у частоті та ефекті збору сміття, а також у кількості поколінь.

У мене було кілька скріншотів, які добре показали різницю, але я не можу відтворити, оскільки у мене 64-бітний JVM, який реалізує лише серверну машину. (І я не можу заважати завантажувати і налаштовувати 32-бітну версію в моїй системі.)

Здається, це вже не так, спробувавши запустити якийсь код на Windows з обома серверними та клієнтськими віртуальними машинами, я, здається, отримав однакову модель покоління для обох ...

Під час переходу з версії 1.4 до 1.7 ("1.7.0_55"). Що ми спостерігали тут, немає таких різниць у значеннях за замовчуванням, призначених для збільшення | 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, під час переходу на форум Open JDK є дискусії, в яких заявлений розмір кадру дещо вищий у версії 1.7. Вважається, що реальну різницю можна було б виміряти під час виконання на основі вашої поведінки вашої заявки