Комментарии 10
Спасибо за интересную статью. По теме есть очень хорошая классическая статья Close Encounters of The Java Memory Model Kind и более старая Java Memory Model Pragmatics. Не знаю, зачем написал это. Это должно что-то значить. Что-то важное.
Спасибо за статью. Будет полезна в качестве базы для обучения начинающих разработчиков, которым тяжело даётся английский.
P.s. возможно, "предшествует" более подходящий кандидат на перевод чем "произошло/случилось до" (хотя, может, просто мода изменилась)
там:
— просто и понятно объясняется чем разные модели друг от друга отличаются
— рассказано про реализацию этих моделей в java (уже есть разные библиотеки)
Слышал, что сборщик мусора может переделать все адреса в памяти, но что-то с трудом верится, что он будет перемалывать всю кучу. По крайней мере это ведет к тому, что надо как-то четко отделять простые данные и ссылки или даже хранить их раздельно, что тоже ведет к доп.расходам.
www.oracle.com/technetwork/java/whitepaper-135217.html
Object references are implemented as direct pointers. This provides C-speed access to instance variables
Сборщик мусора в любом случае «перемалывает всю кучу», то есть он обязан проверить все ссылки на объект перед тем как как удалять/перемещать его. Про «простые данные и ссылки» не очень понял, можете пояснить в чем вы видите проблему?
Для того чтобы многозадачность работала нужна конкуренция.
Вовсе не обязательно. Конкуренция (и все, что было описано выше) нужна там, где появляется shared state и race conditions. Именно для доступа к общей памяти и служат все эти JMM, локи и другие примитивы, а не для управления многозадачностью как таковой. В Unix вы управляете многозадачностью из шелла и строите потоковую обработку данных при помощи pipes, при этом у вас работает параллельно сразу несколько процессов, но отсутствует shared state и конкуренция (по крайней мере въявную).
Почему так популярна модель с потоками?
Потому-что Unix. POSIX-потоки — это эволюция юникс-процессов. На самом деле поток — это отличное средство для изоляции выполнения задачи (еще ничего лучше не придумано): он жестко связан со стеком вызовов (алло, корутины!) и содержит в себе весь контекст выполнения ввиде локальных переменных (привет, коллбеки!). Основным недостатком является жесткая привязанность к ресурсам системы и невозможность сериализации/персистенции, например в случае длительной блокирующей операции. Хотя на этот счет есть свои решения.
Откуда растут ноги у Java Memory Model