questioner,

OutOfMemoryError возникает в ситуации когда поток пытается резервировать для себя память. Будь то куча, стэк, или пермген\метаспэйс. Операция резервирования памяти обрыгивается и выкидывается исключение.
Другие потоки при этом могут не требовать новой памяти и продолжать работать. Могут резервировать меньшее количество памяти и тоже продолжать работать.
OutOfMemoryError при желании можно отловить и продолжить работу текущего потока тоже.

Leonid Kudryavtsevкак-то у меня другое представление об OutOfMemory.

Ну, так нужно его формировать далее.

Leonid KudryavtsevНу и ответ на вопрос "Почему второй поток не умрёт если в первом вылетит OutOfMemoryError ? " мне кажется "не все так однозначно" ( C).
ОК. Опиши тогда сценарий при котром второй поток умрет.

Leonid KudryavtsevКак я понимаю (для обычных GC) OutOfMemory возникает. когда GC не смог освободить память дольше определенного времени. Лично на нашей (практический опыт) системе, если был OutOfMemory, то "поздно пить боржоми, когда почки отвалились". Heap забит под завязку.
Во-первых нет никаких обычных и не обычных GC. Есть разные GC. И у разных GC поведение может отличатся.
Во-вторых OutOfMemoryError не обязательно связан с кучей.
В-третих, OutOfMemoryError кучи вылетает не только по таймауту работы сборки мусора, но и на пример при достижении лимита размера куча, а нам тут резко понадобилась сотня мегабайт для бинарника. GC отработал. Таймаута небыло. Свободного места тоже.

Leonid KudryavtsevAFAIK поведением по выкидыванию OutOfMemory можно управлять. Можно выставить параметр для GC и OutOfMemory вообще никогда не будет, GC будет до посинения пытаться память выделить. (сам не делал)
Не будет по таймауту. Ещё не означает что не будет вообще.

Leonid KudryavtsevКак можно данную ошибку корректно отработать и зачем, лично я не представляю. Но на мой взгляд, subj топика можно перефразировать так "почему второй поток и система может не умереть....". Системы спроектированные по принципе "может не умереть, а может умереть. как повезет" - imho нафиг. Лучше стараться нормально проектировать и нормально конфигурировать JVM, а не что бы система на пределе возможностей работала и потом задавать такие вопросы на собеседовании. IMHO & AFAIK
А мне тут же на форуме буквально год-два рассказывали. Польза, оказывается, бывает в Android. Так как при отображении картинок сложно сказать хватит ли памяти. И всегда можно огрести OOME в неожиданном месте в связи с этим. Таким образом иногда лучше поймкать и сказать, ой у вас картинка не влезла, чем завалить всё приложение и отказать в дальнейшей его работе пользователю.

Leonid KudryavtsevПолез в И-нет, первая попавшаяся статься:
IMHO
Вопрос был не в том нужно или не нужно ловить OOME. Вопрос был в том влияет ли OOME на другие потоки.

questionerЯ думал, что OOM это проблема нехватики памяти в хипе, а хип у потоков общий.

Не все потокам одновременно нужно захватить больше памяти в куче. Некоторым это не нужно вообще. Другим нужно но не достаточно много для ошибки. К тому же, если жадный поток умирает (а OMME обычно не ловят), зачастую, куча всего в хипе освобождается.

questioner...в стэке, или пермген\метаспэйс(слабо понимаю что это за сущности, но не важно)
Фига себе "не важно".

questionerИ ещё важное, что я понял из ответов, что это может быть не проблема того, что памяти мало, а того, что у одного из потов слишком большие запросы. Собственно, если у других потоков запросы поскромнее, то им вполне может хватить этой памяти и ничего не будет.
Да.

maytonК примеру популярный вопрос - сколько Java поддерживает потоков имеет ответ
в стиле Одессы. - А сколько у вас heap? Где-то звучала цифра - 10Мб на поток.

Вобщем если хип закончился то конструктор нового потока обломится. Это
будет положительный ответ на ваш вопрос? думаю да.

Если хип закончился в процессе работы двух потоков - тогда думаю
надо анализировать ситуацию глубже. Смотреть как run() реализован.
Чет я не понял зачем ты стэк с кучей перемешал. Память для стэка на поток выделяется вне кучи же.