Ответ 1
Современные реализации VM резервируют для каждого потока собственную область в куче для создания объектов. Таким образом, не проблема, если эта область не заполняется (тогда сборщик мусора перемещает оставшиеся объекты).
Далее читайте: как работает TLAB в Sun JVM. Azul VM использует немного другой подход (посмотрите на "Новый поток и компоновку стека" ), в статье показано довольно много трюков. JVM могут выполнять за сцены, чтобы обеспечить скорость Java в настоящее время.
Основная идея заключается в том, чтобы поддерживать в потоковой (не разделяемой) области выделение новых объектов, как выделение в стеке с помощью C/С++. Коллекция копий мусора очень быстро освобождает недолговечные объекты, несколько оставшихся в живых, если они есть, перемещаются в другую область. Таким образом, создание относительно небольших объектов происходит очень быстро и заблокировать.
Свободное выделение блокировки очень важно, тем более, что вопрос касается multithreaded environment. Он также позволяет создавать настоящие блокирующие алгоритмы. Даже если сам алгоритм является блокировкой, но выделение новых объектов синхронизируется, весь алгоритм эффективно синхронизируется и в конечном итоге менее масштабируется.
java.util.concurrent.ConcurrentLinkedQueue, основанный на работе Магеда М. Майкла Майкла Л. Скотта - классический пример.
Что происходит, если объект ссылается на другой поток? (из-за обсуждения)
Этот объект (назовите его A) будет перемещен в некоторую зону "оставшегося в живых". Оставшаяся часть пострадавшего проверяется реже, чем области ThreadLocal. Он содержит, как и название, объекты, ссылки которых удалось убежать, или, в частности, A, удалось остаться в живых. Часть копирования (перемещения) происходит во время некоторой "безопасной точки" (безопасная точка исключает правильный код JIT'd), поэтому сборщик мусора уверен, что объект не ссылается. Обновляются ссылки на объект, освобождаются необходимые заготовки памяти и приложение (код Java). Далее прочитайте этот упрощенный сценарий.
Для самого заинтересованного читателя и, если возможно, его жевать: высокоразвитый Бесполезный алгоритм GC