Я трохи розширюю надані відповіді (оскільки поки що вони зосереджуються на своїй "власній" / штучній термінології, орієнтуючись на програмування певної мови, а не дбаючи про більшу картину позаду сцени створення мов програмування , взагалі, тобто коли речі як-от міркування щодо безпеки типу та пам’яті мають значення):
int не булева
Розглянемо
boolean bar = true;
System.out.printf("Bar is %b\n", bar);
System.out.printf("Bar is %d\n", (bar)?1:0);
int baz = 1;
System.out.printf("Baz is %d\n", baz);
System.out.printf("Baz is %b\n", baz);
з виходом
Bar is true
Bar is 1
Baz is 1
Baz is true
Java - код на 3 - му рядку (bar)?1:0показує , що бар ( булево ) не може бути неявно перетворений ( з приведенням) в якості міжнар . Я підводжу це не для того, щоб проілюструвати деталі впровадження JVM, а щоб зазначити, що з точки зору низького рівня (як розмір пам'яті) потрібно віддавати перевагу значенням, ніж безпека типу. Особливо, якщо безпека цього типу не справді / повністю використовується, як у булевих типах, де перевірки проводяться у формі
якщо значення \ в {0,1}, тоді буде передано булевий тип, інакше киньте виняток.
Все, щоб стверджувати, що {0,1} <{-2 ^ 31, .., 2 ^ 31 -1}. Здається, як надмір, так? Безпека типу справді важлива для визначених користувачем типів, а не при неявному відливанні примітивів (хоча останні включаються до першого).
Байти не є типом або бітами
Зауважте, що в пам’яті ваша змінна з діапазону {0,1} все ще буде займати принаймні байт або слово (xbits залежно від розміру регістра), якщо спеціально не береться до уваги (наприклад, добре упаковано в пам'ять - 8 "булевих" біт в 1 байт - вперед і назад).
Віддаючи перевагу безпеці типу (як при введенні / загортанні значення у вікно певного типу) над упаковкою додаткової величини (наприклад, з використанням бітових зрушень або арифметики), ефективно вибирати менше запису коду за рахунок отримання більшої кількості пам'яті. (З іншого боку, завжди можна визначити користувацький тип користувача, який полегшить усі перетворення не варто, ніж Boolean).
ключове слово та тип
Нарешті, ваше питання стосується порівняння ключового слова та типу . Я вважаю, що важливо пояснити, чому або як саме ви отримаєте ефективність, використовуючи / віддаючи перевагу ключові слова ("позначені" як примітивні ) над типами (звичайні складові класи, визначені користувачем, використовуючи інший клас ключових слів ) або іншими словами
boolean foo = true;
vs.
Boolean foo = true;
Перша «річ» (тип) не може бути розширена (підкласична) і не без причини. Ефективно Java-термінологія примітивних та обгорткових класів може бути просто переведена на вбудоване значення (ЛІТЕРАЛЬНА або константа, яка безпосередньо підміняється компілятором, коли можливо зробити висновок про заміну, а якщо ні - все ще резервне перетворення значень).
Оптимізація досягається завдяки тривіальним:
"Менше операцій лиття під час виконання => більша швидкість."
Ось чому, коли зроблено фактичний висновок типу, він може (все-таки) закінчитись примірником класу обгортання з усією інформацією про тип, якщо це необхідно (або перетворенням / виливанням у такі).
Таким чином, різниця між булевих і логічним значенням саме в Збірнику і Час відтворення (трохи далекоглядний , але майже так само InstanceOf проти GetClass () ).
Нарешті, автобоксинг проходить повільніше, ніж примітивні
Зауважте, що Java може робити автобоксинг - це лише «синтаксичний цукор». Це нічого не прискорює, просто дозволяє писати менше коду. Це воно. Відливання та загортання у контейнер для інформації типу все ще виконується. З міркувань продуктивності вибирайте арифметику, яка завжди буде пропускати додаткові послуги по створенню екземплярів класу з інформацією про тип для забезпечення безпеки типу. Відсутність безпеки типу - це ціна, яку ви платите за отримання продуктивності. Для коду з виразами з булевими значеннями тип безпеки (коли ви пишете менше і, отже, неявний код) буде критичним, наприклад, для управління потоками if-then-else.