почему Память "кучи" использования в Java
Почему мы используем Память "кучи", мы можем использовать Стековую память для того же?
ОТРЕДАКТИРОВАННЫЙ
Еще один вопрос прибыл в мой ум после чтения ответов, 1) там какой-либо другой вид памяти, которая мы можем думать об альтернативе "куче" и Стеку?
Отредактированный
Я столкнулся со строковым пулом, та память связана с "кучей" или Стеком?
6 ответов
Итак, у вас есть для использования кучи, если вы хотите использовать объекты. По сути, объекты являются указателями в стеке (или внутри других объектов) на фрагменты памяти в куче.
В отличие от C ++, где вы можете помещать объекты в стек или кучу, Java работает иначе.
Даже в C ++ рекомендуется использовать кучу для объектов, которые должны пережить функцию, в которой они были созданы. Вы, вероятно, сможете этого избежать, но можете столкнуться с проблемой производительности со всеми копировать конструкторы.
Что касается вашего редактирования:
Есть ли какой-либо другой вид памяти, который мы можем придумать как альтернативу кучи и стеку?
Конечно, есть: статические элементы данных, те, в которых только один на класс, а не один на каждый экземпляр объекта должен куда-то идти. Их не может быть в стеке, так как они могут исчезнуть при выходе из функции. И они не могут принадлежать определенному объекту.
Они (по крайней мере, в Sun / Oracle JVM) входят в область методов.
Кроме того, вы не должны думать об одном стеке. Каждый поток при создании получает свой стек.
Также есть пул констант времени выполнения и стеки для нативных (не Java) вызовов.
Есть много информации о внутреннем устройстве JVM здесь относительно этого аспекта, но имейте в виду, что между логической машиной и реализацией может быть различие.
В JVM вместо локального стека потока для объектов он использует буфер локального распределения потока или (TLAB). Это дает большую часть преимуществ стека производительности, при этом разработчику не нужно беспокоиться о том, находится ли объект в стек или нет.
Можем ли мы использовать стековую память для того же?
В основном нет.
В Java стековая память используется исключительно для параметров и локальных переменных методов (и некоторой скрытой бухгалтерской информации, которая не имеет отношения к этому обсуждению). И для этих переменных только примитивные типы используют только стековую память. Любой объект или массив представлен как ссылка на что-то в куче, а Java не предоставляет возможности выделить объект или массив в стеке.
[В сторону: теоретически возможно выполнять любые вычисления в Java, используя только примитивные типы и рекурсивные статические методы. Однако это было бы ужасно беспорядочно. Даже написание простого сообщения на консоль повлечет за собой размещение вашим приложением объектов в куче. Так что мы можем отклонить это как совершенно непрактичное.]
Еще одним важным фактором, который следует учитывать, является определение области действия. Если все объекты должны быть размещены в стеке, они выходят из контекста при развертывании кадра стека. С точки зрения непрофессионала, думайте о стеке как о дампе, в котором хранятся все значения переменных и ссылки на объекты, которые являются локальными для подпрограммы / метода, которые в настоящее время находятся в области видимости. Как только он завершит выполнение (или метод выйдет за пределы области видимости), все в нем будет потеряно.
Куча памяти занимает центральное место в Java. Все объекты размещаются в куче, а локальные переменные содержат только ссылки (по сути, указатели) на них. C # позволяет вам иметь объекты (типы значений), которые живут в стеке. Java решила не заимствовать это из C ++, отчасти для того, чтобы упростить язык.
В разных языках память в виде кучи - это способ предоставить долгоживущие объекты произвольного размера.
Это упрощает компилятору управление большими и / или переменными динамического размера - они по-прежнему занимают небольшое постоянное хранилище в стеке вызовов - 4 байта (указатель кучи).