Немного оффтопа о многопоточности и многопроцессорности.
А есть ещё и распараллеливание вычислений, это вообще немножко третье.
Когда кто-то начинает говорить о многопроцессорности, то всегда надо просить его уточнить что конкретно говорящий имеет ввиду.
Из самих терминов уже видно, что это несколько разные понятия. Правильно всё разложить по потокам, а потоки по ядрам - это всегда крайне сложная задача. Распараллеливание вычислений вообще особая статья, для тех, кто силён в технической части и математике.
Вопрос синхронизации потоков не является большой проблемой, весь необходимый набор API существует с давних пор. Все нюансы синхронизации должны в голове быть сложены, разработчик многопоточного приложения должен чётко осознавать что и для чего нужно по разным потокам раскидывать и как эти потоки должны между собой взаимодействовать. И если он в потоки знает и умеет, то работа с ними вообще ни каких сложностей не представляет. Ещё раз, это, в первую очередь, вопрос выбора правильной архитектуры для проекта, архитектуры в плане бизнес логики, а не технической, технические аспекты вопрос платформы на которой/которых мы планируем крутиццо.
Параллельно мы смотрим на ядра, сейчас уже можно планировать исходя из допущения, что ядер у нас всегда будет больше одного. Есть два принципиально разных подхода к планированию нагрузки на ядра, один обеспечивает максимально быстрый отклик на входящие события, второй - максимальную загруженность ядра. Из этого понятно, что тут основная сложность в выборе оптимального баланса отдельных частей нашего приложения. Если о графике для примера, то для максимальной производительности одно ядро должно быть постоянно занято подготовкой данных для видео адаптера, но оно всё равно будет значительную часть времени недогружено, ибо сцена может меняться не достаточно динамично. И у нас может появиться соблазн подкинуть на это ядро ещё каких-то потоков, чтоб "не простаивало". А потом, вруг!
, при эксплуатации в какие-то моменты у нас резкие просадки производительности начинают вылезать, хотя сцену мы строили исходя из данных профилёра. На этом этапе и в этой части рулит правильный выбор изначальной стратегии и качественное, всеобъемлющее тестирование результата.
О распараллеливании ничего писать не буду, слишком сложно и с этим мало дела имел, в основном для себя. Да и не особо его в нашем случае есть где использовать.
Ну и о грустном. Ява не самый лучший выбор для задач в которых мы хотим достичь макс. производительности. В нашем случае нужно кардинально менять подход к архитектуре, убирать из ява-кода все вычисления оставляя ей только генерацию событий и реакцию на них, а всё остальное переносить в нативный код.
Как-то так.