Каков размер логической переменной в Java?
Хотите указать на некоторые документы? Мне трудно поверить, что размер логического значения зависит от машины. Это будет означать, что двоичное представление класса, содержащего логическое значение, будет иметь разные размеры (и схемы памяти) в разных виртуальных машинах, и это будет означать, что виртуальные машины будут несовместимы.
Я думаю, что подразумевалось, что вопрос касается размера логической переменной в памяти, а не размера логической переменной, закодированной в файле класса. Размер памяти зависит от виртуальной машины в соответствии с документацией Sun. Размер в файле класса является постоянным.
@DavidRodríguez-dribeas DavidRodríguez-dribeas — JVM от Sun во времена Java 1.1 использовала 4 байта для логического значения при хранении в качестве экземпляра или auto var. Это упростило реализацию интерпретатора байт-кода (который рассматривает bools как занимающие 4 байта в стеке) и стало путем наименьшего сопротивления. Когда мы внедрили iSeries «Classic» JVM, мы нашли способы сделать экземплярные переменные размером 1 байт, поскольку это значительно улучшило компактность некоторых объектов (что оказывает потрясающее влияние на производительность). Судя по сообщениям, приведенным ниже, разработчики Sun / Oracle выяснили, как это сделать в более поздних версиях.
Но это верно, по состоянию на конец 2017 года JavaDocs говорят: boolean: The boolean data type. This data type represents one bit of information, but its «size» isn’t something that’s precisely defined — но ваша точка зрения верна, она можно использовать некоторые ссылки и лучшую информацию 🙂
Это зависит от виртуальной машины, но легко адаптировать код из аналогичного вопроса о байтах в Java:
class LotsOfBooleans < boolean a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, aa, ab, ac, ad, ae, af; boolean b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, ba, bb, bc, bd, be, bf; boolean c0, c1, c2, c3, c4, c5, c6, c7, c8, c9, ca, cb, cc, cd, ce, cf; boolean d0, d1, d2, d3, d4, d5, d6, d7, d8, d9, da, db, dc, dd, de, df; boolean e0, e1, e2, e3, e4, e5, e6, e7, e8, e9, ea, eb, ec, ed, ee, ef; >class LotsOfInts < int a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, aa, ab, ac, ad, ae, af; int b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, ba, bb, bc, bd, be, bf; int c0, c1, c2, c3, c4, c5, c6, c7, c8, c9, ca, cb, cc, cd, ce, cf; int d0, d1, d2, d3, d4, d5, d6, d7, d8, d9, da, db, dc, dd, de, df; int e0, e1, e2, e3, e4, e5, e6, e7, e8, e9, ea, eb, ec, ed, ee, ef; >public class Test < private static final int SIZE = 1000000; public static void main(String[] args) throws Exception < LotsOfBooleans[] first = new LotsOfBooleans[SIZE]; LotsOfInts[] second = new LotsOfInts[SIZE]; System.gc(); long startMem = getMemory(); for (int i=0; i < SIZE; i++) < first[i] = new LotsOfBooleans(); >System.gc(); long endMem = getMemory(); System.out.println ("Size for LotsOfBooleans: " + (endMem-startMem)); System.out.println ("Average size: " + ((endMem-startMem) / ((double)SIZE))); System.gc(); startMem = getMemory(); for (int i=0; i < SIZE; i++) < second[i] = new LotsOfInts(); >System.gc(); endMem = getMemory(); System.out.println ("Size for LotsOfInts: " + (endMem-startMem)); System.out.println ("Average size: " + ((endMem-startMem) / ((double)SIZE))); // Make sure nothing gets collected long total = 0; for (int i=0; i < SIZE; i++) < total += (first[i].a0 ? 1 : 0) + second[i].a0; >System.out.println(total); > private static long getMemory() < Runtime runtime = Runtime.getRuntime(); return runtime.totalMemory() - runtime.freeMemory(); >> Повторить, это зависит от VM, но на моем ноутбуке Windows, работающем под Sun JDK build 1.6.0_11, я получил следующие результаты:
Size for LotsOfBooleans: 87978576 Average size: 87.978576 Size for LotsOfInts: 328000000 Average size: 328.0 Это говорит о том, что булевы в основном могут быть упакованы в байты каждый с помощью Sun JVM.
@warrior: Поскольку я уже получил код для «байта», изменить его на «логический» было довольно просто 🙂
System.gc () не гарантирует очистку памяти. Он просто дает JVM команду запустить сборку мусора, но это не значит, что сборщик действительно что-то очистил. Помните, что коллектор очищает НЕиспользуемые объекты. Объект не используется, если в программе больше нет ссылок на него. Поэтому в вашем тесте я бы явно отбросил ссылку, установив для LotsOfBooleans значение null перед запуском gc (); ИЛИ просто запустите main один раз с логическим значением, один раз с int, затем сравните числа.
@RandaSbeity Или даже лучше: убедитесь, что вы сохранили обе ссылки и рассчитали разницу в памяти. Что именно здесь и происходит.
Для неосторожного взгляда эти числа в выходных данных должны быть разделены на 80, потому что в классах имеется 80 элементов, чтобы получить окончательный результат, утвержденный Ответом.
Фактическая информация, представленная логическим значением в Java, является одной бит: 1 для true, 0 для false. Однако фактический размер булевой переменной в памяти точно не определен спецификацией Java. См. Примитивные типы данных в Java.
Булевский тип данных имеет только два возможные значения: true и false. использование этот тип данных для простых флагов, которые отслеживать истинные/ложные условия. Эти данные тип представляет собой один бит информации, но его «размер» не то, что точно определено.
Тайны самого простого типа в Java
На одном из собеседований мне задали вопрос: так, сколько байт занимает переменная типа boolean в памяти? А типа Boolean?
Я, не долго думая, выпалил, что, мол о каких байтах речь, наверняка boolean в Java занимает 1 БИТ, а восемь флажков так и вообще 1 БАЙТ.
Мне сказали, что я не прав, в Java все иначе и вообще, идите, учите матчасть.
Типы в Java и их размеры
Я думаю вы часто встречали что-то вроде такого:
| Type | Size in Bytes | Range |
|---|---|---|
| byte | 1 byte | -128 to 127 |
| short | 2 bytes | -32,768 to 32,767 |
| int | 4 bytes | -2,147,483,648 to 2,147,483, 647 |
| long | 8 bytes | -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 |
| float | 4 bytes | approximately ±3.40282347E+38F (6-7 significant decimal digits) Java implements IEEE 754 standard |
| double | 8 bytes | approximately ±1.79769313486231570E+308 (15 significant decimal digits) |
| char | 2 byte | 0 to 65,536 (unsigned) |
| boolean | not precisely defined* | true or false |
Табличка, где boolean стыдливо обходится стороной и замалчивается как бедный родственник, отсидевший в тюрьме за кражу поддельного айфона из перехода.
Согласно официальному туториалу от Sun/Oracle мы видим следующую картину для народных масс: boolean представляет 1 бит информации, но размер остается на совести того, кто воплощает спеку JVM.
Заглядывая в спеку JVM
Собственно в спеке, на одной из первых страниц [стр.20], мы видим приписку, что, мол boolean в ранних спеках и за тип не считался, настолько он специфический. Впрочем, параграф 2.3.4, приоткрывает завесу тайны над идеями имплементации boolean на конкретной виртуальное машине.
There are no Java Virtual Machine instructions solely dedicated to operations on boolean values. Instead, expressions in the Java programming language that operate on boolean values are compiled to use values of the Java Virtual Machine int data type.
Т.е. нам ясно говорят, что в целом boolean внутренне — это типичный 4-байтовый int. Соответственно, переменная типа boolean, скорее всего будет занимать 4 байта (в 32 раза больше, чем само значение, которое она презентует).
Проверяя bytecode
public class Sample < public static void main(String[] args) < boolean flag = true; flag = false; > > и поглядим в его bytecode
// class version 52.0 (52) // access flags 0x21 public class experiment/Sample < // compiled from: Sample.java // access flags 0x1 public ()V L0 LINENUMBER 3 L0 ALOAD 0 INVOKESPECIAL java/lang/Object. ()V RETURN L1 LOCALVARIABLE this Lexperiment/Sample; L0 L1 0 MAXSTACK = 1 MAXLOCALS = 1 // access flags 0x9 public static main([Ljava/lang/String;)V L0 LINENUMBER 5 L0 ICONST_1 ISTORE 1 L1 LINENUMBER 6 L1 ICONST_0 ISTORE 1 L2 LINENUMBER 7 L2 RETURN L3 LOCALVARIABLE args [Ljava/lang/String; L0 L3 0 LOCALVARIABLE flag Z L1 L3 1 MAXSTACK = 1 MAXLOCALS = 2 > Мы видим тут замечательные ICONST_1/ICONST_0 — это специальные инструкции для JVM, чтобы положить на стек 1 и 0, соответственно. Т.е. good-old true/false превращаются в 1 и 0. А нам еще запрещают в java писать выражения ‘true + 1’
INT? Ну серьезно? Почему не short или byte? Почему огромный многословный int? Это вызывает вопросы, на которые я попробую ответить ближе к концу статьи.
А массивы?
Кажется, что должно быть все грустно. Массив из десятка boolean будет занимать столько же места, что и массив из десятка int-ов. Как бы не так!
В той же спеке, в параграфе 2.3.4, говорится
The Java Virtual Machine does directly support boolean arrays. Its newarray instruction (§newarray) enables creation of boolean arrays. Arrays of type boolean are accessed and modified using the byte array instructions baload and bastore (§baload, §bastore).
Поглядим байткод для одного такого массива с парочкой изменяемых элементов.
boolean[] flags = new boolean[100000]; flags[99999] = false; flags[88888] = true && false; // class version 52.0 (52) // access flags 0x21 public class experiment/Sample < // compiled from: Sample.java // access flags 0x1 public ()V L0 LINENUMBER 5 L0 ALOAD 0 INVOKESPECIAL java/lang/Object. ()V RETURN L1 LOCALVARIABLE this Lexperiment/Sample; L0 L1 0 MAXSTACK = 1 MAXLOCALS = 1 // access flags 0x9 public static main([Ljava/lang/String;)V L0 LINENUMBER 9 L0 LDC 100000 NEWARRAY T_BOOLEAN ASTORE 1 L1 LINENUMBER 10 L1 ALOAD 1 LDC 99999 ICONST_0 BASTORE L2 LINENUMBER 11 L2 ALOAD 1 LDC 88888 ICONST_0 BASTORE L3 LINENUMBER 14 L3 RETURN L4 LOCALVARIABLE args [Ljava/lang/String; L0 L4 0 LOCALVARIABLE flags [Z L1 L4 1 MAXSTACK = 3 MAXLOCALS = 2 > Ура, новые операции видны. Впрочем наши любимые ICONST_0 никто не отменял.
Там же идет мелким шрифтом, как часть контракта, которую никто не читает
In Oracle’s Java Virtual Machine implementation, boolean arrays in the Java programming language are encoded as Java Virtual Machine byte arrays, using 8 bits per boolean element.
Грубо говоря, парни, на правильных JVM все не так плохо и мы можем сэкономить на счетах за электричество.
Уже британскими учеными разработаны новейшие инструкции для загрузки и выгрузки значений в такой массив, да и сам массив будет задействовать только по 1 байту на элемент.
Ну что, неплохо, но надо проверять.
Я давно не доверяю методам замера памяти а-ля Runtime.getRuntime().freeMemory(), поэтому я воспользовался библиотечкой JOL из состава OpenJDK.
dependency> groupId>org.openjdk.jol groupId> artifactId>jol-core artifactId> version>0.8 version> dependency> Там есть простая возможность узнать размеры элемента массива для вашей конкретной JVM
System.out.println(VM.current().details()); Результат оказался ожидаемым, наш элемент и вправду занимает 1 байт на моей машине вместе с Oracle JDK 1.8.66
# Running 64-bit HotSpot VM. # Using compressed oop with 3-bit shift. # Using compressed klass with 3-bit shift. # Objects are 8 bytes aligned. # Field sizes by type: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes] # Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes] А что насчет типа Boolean?
Вот уж кто, наверное, жрет памяти за обе щеки.
А вот и нет, вполне себе скромный честный труженик с тратой памяти на заголовок и выравнивание
header: 8 bytes value: 1 byte padding: 7 bytes ------------------ sum: 16 bytes Что же делать?
Ну если вам нужен именно тип boolean, он у вас во всех сигнатурах и т.д. — то ничего не делать, сидеть на попе ровно и ждать 50 релиза Java, может там престарелый Леша Шиппелoff научится распихивать свои стринги по карманам boolean.
Если дело только в эффективных структурах данных, то даже в самой Java есть кое-что на закуску. Это https://docs.oracle.com/javase/8/docs/api/java/util/BitSet.html
Это структура данных, умеющая оперировать набором логических значений как набором бит. Впрочем с boolean она несовместима. Ее можно использовать для эффективного представления в памяти достаточно больших наборов.
import java.util.BitSet; public class BitSetDemo < public static void main(String args[]) < BitSet bits1 = new BitSet(16); BitSet bits2 = new BitSet(16); // set some bits for(int i = 0; i < 16; i++) < if((i % 2) == 0) bits1.set(i); if((i % 5) != 0) bits2.set(i); > System.out.println("Initial pattern in bits1: "); System.out.println(bits1); System.out.println("\nInitial pattern in bits2: "); System.out.println(bits2); // AND bits bits2.and(bits1); System.out.println("\nbits2 AND bits1: "); System.out.println(bits2); // OR bits bits2.or(bits1); System.out.println("\nbits2 OR bits1: "); System.out.println(bits2); // XOR bits bits2.xor(bits1); System.out.println("\nbits2 XOR bits1: "); System.out.println(bits2); > > Initial pattern in bits1: Initial pattern in bits2: bits2 AND bits1: bits2 OR bits1: bits2 XOR bits1: <> Почему сразу не сделали хорошо?
Во-первых, я думаю дело в том, что адресоваться к битам неудобно и сложно. Все заточено под байты — адресная арифметика, всякие машинные команды и прочее. Очень сложно подойти к биту и попытаться выполнить на нем какое-то адресное смещение. Да и вряд ли такая операция будет дешевой — мы все равно будем тратиться на обращение к байту и поиск в нем искомого бита., чтобы установить его или сбросить.
Во-вторых, и byte и short не являются полноценными численными типами, над ними довлеет проклятие int и его целочисленных операций, вряд ли бы мы смогли существенно сэкономить, перегоняя boolean->byte->int