Комментарии 10
Спасибо за интересную статью. По теме есть очень хорошая классическая статья под авторством Jeremy Manson и Brian Goetz, сжато и по-возможности несложно описывающая JMM: JSR 133 (Java Memory Model) FAQ. На Хабре проскакивал перевод.

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


P.s. возможно, "предшествует" более подходящий кандидат на перевод чем "произошло/случилось до" (хотя, может, просто мода изменилась)

про разные модели concurrency имхо неплохо рассказано в этом видео www.youtube.com/watch?v=EMv_8dxSqdE
там:
— просто и понятно объясняется чем разные модели друг от друга отличаются
— рассказано про реализацию этих моделей в java (уже есть разные библиотеки)
Не знаю какой вариант правильный, встречаются оба варианта. В большинстве публикаций наблюдаю вариант конкуренция, например тут, тут.

"Конкуренция" намекает на глагол, в том плане, что это за этим словом стоит некий процесс. А "конкурентность", мне ощущается как свойство, т.е. существительное произошедшие по смыслу от прилагательного.


Т.е. думаю оба слова разумное использовать, главное видеть оттенки.

Подскажите, где почитать, — какие накладные расходы связаны с адресацией данных в памяти, связанные с тем, что данные могут перемещаться сборщиком мусора? В представлении С память является линейным массивом без разделов и данные не могут внезапно переместиться. Поэтому адресация данных происходит в один этап — получаем адрес и лезем по адресу. В джаве надо как-то каждый раз вычислять этот адрес, прежде, чем по нему сбегать за данными. Вот интересно — какие расходы связаны с этим?

Слышал, что сборщик мусора может переделать все адреса в памяти, но что-то с трудом верится, что он будет перемалывать всю кучу. По крайней мере это ведет к тому, что надо как-то четко отделять простые данные и ссылки или даже хранить их раздельно, что тоже ведет к доп.расходам.

Вообще это зависит от JVM, но если вопрос про HotSpot, то адресация происходит в 1 этап, как в С.

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-потоки — это эволюция юникс-процессов. На самом деле поток — это отличное средство для изоляции выполнения задачи (еще ничего лучше не придумано): он жестко связан со стеком вызовов (алло, корутины!) и содержит в себе весь контекст выполнения ввиде локальных переменных (привет, коллбеки!). Основным недостатком является жесткая привязанность к ресурсам системы и невозможность сериализации/персистенции, например в случае длительной блокирующей операции. Хотя на этот счет есть свои решения.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.