Используются ли примитивы Java в стеке или куче?

Я просто знаю, что не-примитивы (объекты) идут в кучу, а методы идут в стек, но как насчет примитивных переменных?

–Обновить

На основании ответов я могу сказать, что куча может иметь новый стек и кучу для данного объекта? Учитывая, что объект будет иметь примитивные и ссылочные переменные ..?

Примитивы, определенные локально, будут находиться в стеке. Однако, если примитив был определен как часть экземпляра объекта, этот примитив был бы в куче.

public class Test { private static class HeapClass { public int y; // When an instance of HeapClass is allocated, this will be on the heap. } public static void main(String[] args) { int x=1; // This is on the stack. } } 

Что касается обновления:

Объекты не имеют собственного стека. В моем примере int y действительно будет частью каждого экземпляра HeapClass . Всякий раз, когда выделяется экземпляр HeapClass (например, new HeapClass() ), все переменные-члены HeapClass добавляются в кучу. Таким образом, поскольку экземпляры HeapClass выделяются в куче, int y будет находиться в куче как часть экземпляра HeapClass .

Однако все примитивные переменные, объявленные в теле любого метода, будут в стеке.

Как вы можете видеть в приведенном выше примере, int x находится в стеке, потому что он объявлен в теле метода – не как член classа.

Все локальные переменные (включая аргументы метода) идут в стек; объекты и все их поля хранятся в куче. Переменные всегда являются примитивами или ссылками на объекты.

Реализации Java могут фактически хранить объекты в куче таким образом, чтобы они все еще соответствовали спецификации. Точно так же локальные переменные могут храниться в регистрах или становиться нечеткими с помощью оптимизации.

примитивы можно найти в обоих местах.

 class Foo { public int x; public static void Main() { int y = 3; // y is on the stack Foo f = new Foo(); // fx is probably on the heap } } 

за исключением того, что вам небезразлично, если вы не создаете JVM. Действительно умный оптимизатор может решить, что, поскольку Foo, что f указывает на то, что никогда не ускользает от Main, и никогда не переходит к другой функции, можно безопасно выделить его в стеке.

Что касается обновления:

Стек и куча не отличаются тем, что хранится в них, а скорее операциями, предусмотренными для них. Стек позволяет вам выделить кусок памяти в режиме LIFO, вы не можете освободить кусок, пока все части моложе его не будут освобождены. Это удобно сочетается с тем, как используется стек вызовов. Вы можете поместить что-нибудь в стек, если это нормально, когда эта вещь возвращается, когда ваша функция возвращается. Это оптимизация, так как очень быстро выделять и освобождать из стека, поскольку она поддерживает только то, что используется таким образом. Можно было бы сохранить все локальные переменные для функции в куче в реализации, если захотите. Куча более гибкая и, следовательно, более дорогая в использовании. Неверно было бы сказать, что у объекта есть стек и куча, как я уже сказал, что отличает стек от кучи не то, что в нем, а доступные операции.

Примитивные значения выделяются в стеке, если они не являются полями объекта, и в этом случае они переходят в кучу. Стек используется для оценки и выполнения, поэтому нет смысла говорить, что объекты с примитивными полями имеют стек – он по-прежнему считается частью кучи. Даже объекты Stack выделяются в куче.

Я думаю, что это поможет: (JVM внутренности)

Внутренние устройства JVM

  • Шаги в процессе выделения памяти для объектов Java
  • Как предотвратить создание объекта в куче?
  • Размер кучи Android на разных телефонах / устройствах и версиях ОС
  • Где находится ссылка на переменную, в стеке или в куче?
  • g ++ размер массива без предупреждения?
  • Недопустимый адрес кучи и фатальный сигнал 11
  • Поля classа, хранятся ли они в стеке или куче?
  • Есть ли способ снизить кучу Java, когда он не используется?
  • Управление памятью, повреждение кучи и C ++
  • Распределение памяти: стек против кучи?
  • Как определяется размер кучи Java по умолчанию?
  • Давайте будем гением компьютера.