Как Java обрабатывает память в отношении одноименных локальных переменных, объявленных внутри разных невложенных блоков кода внутри метода?

Во время выполнения на переменные ссылаются не по их именам, а по идентификатору слота (это int). Поэтому проблем с перекрытием не возникает.

Но если вы углубитесь в территорию JIT, идентификатор слота превратится в смещение от начала кадра стека.

Локальные переменные не существуют. Совсем.

Java — это многоэтапный процесс. Сначала компилятор (javac.exe) превращает .java файлы в .class файлы. Затем среда выполнения (java.exe) запускает файл класса.

Во время этого первого шага (компиляции), который очень шаблонен (в спецификации точно указано, как работает javac). В отличие от компиляторов C, которым разрешено, например, выполнять глубокий анализ вашего кода, определять, что цикл не имеет сторон. никаких эффектов и просто полностью исключите их из исполняемого файла, который создает gcc), локальные переменные теряются.

В частности, в формате файла класса система использует нечто совсем другое — стек и слоты.

Любой метод объявляет, сколько «слотов» ему нужно. Спецификация Java работает следующим образом: спецификация определяет, что должно произойти и какие гарантии должны быть предоставлены. Никогда не разъясняется, как все делается. Но иногда объяснить одно конкретное «как» проще, чем пытаться углубиться в спецификацию. Помните, что здесь описано, как это делает большинство JVM, но реализация JVM не обязана:

• Любой метод, который объявляет, скажем, «Я хочу 5 слотов», приводит к тому, что при входе указатель стека увеличивается на 5. Верификатор класса Java уже проверяет, что любой данный метод не может «вытащить» из стека больше значений, чем он «толкает».
• Методы всегда начинаются с параметров, уже помещенных в стек. Среда выполнения решает, как рифмовать этот пункт и предыдущий - он может поменять их местами со «слотами», или сохранить «слоты» в другом месте, или сохранить слоты в конце, или проверить, сколько места в стеке ему нужно, и оставьте «слоты» за этим.
• Метод состоит из байт-кода и выполняется.

Байт-код не относится к «локальным переменным», поскольку они не существуют в байт-коде. Вместо этого байт-код может:

• Обратитесь к стеку, например POP, который удаляет и отбрасывает верхнюю часть стека, или FADD, который извлекает 2 значения из стека, JVM взрывается, если они не являются числами с плавающей точкой (поэтому мы можем предположить, что это так), добавляет два числа с плавающей запятой и помещает их обратно в стек. (Примечание: проверяющий проверяет, что ситуация «взрыва» не может возникнуть. Это звучит более драматично, чем есть на самом деле).
• Запустите некоторый байт-код, который ссылается на слот. Например, ALOAD_1 — это простая инструкция байт-кода, которая извлекает ссылку на объект из «слота №1» (это будет второй слот — первый слот — это слот №0) и помещает ее в стек.

Таким образом, этот Java-код:

int a = readInt();
int b = readInt();
println(a + b);

может быть скомпилировано как:

[START METHOD]
[META: SLOT SIZE: 2]

// int a = readInt(); - 'a' translates to slot 0.
INVOKESTATIC com.foo.KeyboardInput readInt()I;
ISTORE_0

// int b = readInt(); - 'b' translates to slot 1.
INVOKESTATIC com.foo.KeyboardInput readInt()I
ISTORE_1

ILOAD_0 // load int value in slot 0 and push onto stack.
ILOAD_1 // load int value in slot 1 and push onto stack.
IADD    // pop 2 int values, add them, push it back
INVOKESTATIC com.foo.BasicOutput println(I)V

Где println потребляет 1 целое число из стека.

Давайте теперь «придумаем» наш метод и представим еще одну локальную переменную:

int a = readInt();
int b = readInt();
int c = a + b;
println(c);

Этот код легко определить как полностью идентичный по действию первому. И если вы скомпилируете это, это фактически создаст точно такой же байт-код. Никакого «третьего слота» не появится. Потому что в этом нет необходимости — компилятор не переводит локальную переменную «один к одному» в слот. Пока вы не используете c где-либо еще, javac вполне способен осознать, что нет необходимости в его существовании как слоте.

Фактически, если бы вы скомпилировали приведенный выше код, вы бы получили… вообще никаких слотов! В конце концов, если это весь метод и a/b/c больше нигде не используются, компилятор выдаст:

[START METHOD]
[META: SLOT SIZE: 2]

// readInt(); - just leave the read value on the stack.
INVOKESTATIC com.foo.KeyboardInput readInt()I;

// read a second value from the stack
INVOKESTATIC com.foo.KeyboardInput readInt()I

IADD    // pop 2 int values, add them, push it back
INVOKESTATIC com.foo.BasicOutput println(I)V

Нет необходимости даже в одном слоте.

Аналогичным образом представьте себе этот метод:

void example() {
  int a = ....;
  int b = ....;
  // Tons and tons of math with a and b.
  println(a + b);

  // from here on out, a and b are never used again.

  int c = ....;
  int d = ....;
  // Tons and tons of math with c and d.
  // note that a and b are not used in this code
}

Компилятор будет использовать не более двух слотов. Потому что «c» и «d» просто g там, где раньше были «a» и «b». Компилятор вполне способен прийти к выводу, что «a» и «b», поскольку они больше не используются, могут быть «перезаписаны».

Следовательно, однозначного сопоставления локальных переменных со слотами просто не существует:

• Локальная переменная может вообще не привести к созданию слота.
• Один слот может служить местом хранения нескольких локальных файлов.
• Слот может быть объявлен, даже если не существует ни одной локальной переменной.
• Одна локальная переменная может в конечном итоге использоваться в разных позициях слота.
• Слот 0 всегда зарезервирован для ссылки this в методах экземпляра.
• Имена локальных переменных не находятся в файлах классов. Файлу класса не обязательно знать, что переменные в наших математических частях называются «a» и «b». Это освобождает — называйте переменные как хотите. Предпочтительно, что-то, что четко указывает на то, что они делают. Если вы выберете более длинные имена, это не повлияет ни на размер файла класса, ни на скорость его работы. В отличие от, например, javascript, где теоретически это возможно, и минимизаторы JS любят продвигать идею о том, что это не только делает вещи меньше, но и ускоряет их. Ничего из этого не относится к Java. Java всегда быстрая.

Учитывая весь этот контекст, ваш вопрос стал бессмысленным: локальные переменные не существуют в файлах классов, поэтому вопрос «как JVM обращается с двумя локальными переменными с одинаковым именем» тривиален.