Я немного расширяю предоставленные ответы (поскольку до сих пор они концентрируются на своей "собственной" / искусственной терминологии, сосредотачиваясь на программировании определенного языка, вместо того, чтобы заботиться о более широкой картине за сценой создания языков программирования , в общем, то есть, когда такие вещи, как безопасность типов и память, имеют значение):
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 показывает, что bar ( boolean ) не может быть неявно преобразован (приведен) в INT .Я говорю об этом не для того, чтобы проиллюстрировать детали реализации JVM, а чтобы подчеркнуть, что с точки зрения низкого уровня (как объем памяти) нужно отдавать предпочтение значениям над безопасностью типов.Особенно, если безопасность этого типа не используется полностью / полностью, как в булевых типах, где проверки выполняются в форме
, если значение \ in {0,1} затем приведено к булевому типу, в противном случае выдается исключение.
Все только для того, чтобы заявить, что {0,1} <{-2 ^ 31, .., 2 ^ 31 -1}.Похоже на излишество, верно?Безопасность типов действительно важна для пользовательских типов, а не для неявного приведения примитивов (хотя последние включены в первый). </p>
Байты не являются типами или битами
Обратите внимание, что в памяти ваша переменная из диапазона {0,1} будет по-прежнему занимать как минимум байт или слово (xbit в зависимости от размера регистра), если специально не позаботиться об этом (например, красиво упаковано в памяти - 8 «логическое значение»)биты в 1 байт - назад и вперед).
Предпочитая безопасность типов (например, помещая / упаковывая значение в ящик определенного типа), а не упаковывая дополнительные значения (например, используя сдвиги битов или арифметику), можноэффективно выбирает написание меньшего кода, чем получение большего объема памяти.(С другой стороны, всегда можно определить пользовательский тип пользователя, который облегчит все преобразования, не соответствующие булевому значению).
ключевое слово против типа
Наконец, вашвопрос о сравнении ключевого слова с типом .Я считаю, что важно объяснить, почему или как именно вы будете получать производительность, используя / предпочитая ключевые слова («помеченные» как примитив ) над типами (обычные составные определяемые пользователем классы, использующие другое ключевое слово class ) или другими словами
boolean foo = true;
против
Boolean foo = true;
Первая «вещь» (тип) не может быть расширена (подкласс) и не без причины.По сути, терминология Java классов примитивов и обтекания может быть просто переведена в значение inline (LITERAL или константу, которая подставляется напрямую компилятором всякий раз, когда это возможновыведите подстановку или, если нет - все равно вернетесь к переносу значения).
Оптимизация достигается за счет тривиальности:
"Меньше времени выполнения операций приведения => больше скорости."
Именно поэтому при фактическом выводе типасделано, это может (все еще) закончиться созданием экземпляра класса-обертки со всей информацией о типах, если это необходимо (или преобразованием / приведением к такому типу).
Итак, разница между boolean и Boolean точно в Компиляции и Runtime (немного далеко, но почти как instanceof против getClass () ).
Наконец, автобокс медленнее, чем примитивы
Обратите внимание на тот факт, что Java может делать autoboxing - это просто "синтаксический сахар". Это ничего не ускоряет, просто позволяет писать меньше кода. Вот и все. Приведение и упаковка в контейнер информации о типе все еще выполняется. По соображениям производительности выбирайте арифметику, которая всегда будет пропускать дополнительные операции по созданию экземпляров классов с информацией о типах для реализации безопасности типов. Отсутствие типа безопасности - это цена, которую вы платите за повышение производительности. Для кода с булевыми выражениями безопасность типа (когда вы пишете меньше и, следовательно, неявный код) будет иметь решающее значение, например. для управления потоком if-then-else.