Обзор современного состояния средств поддержки многопоточности в java

Основные тезисы:

1) Из-за технических ограничений сложно наращивать частоту процессоров, но зато можно сделать много ядер;

2) Существует много задач, которые допускают параллельное исполнение каких-то из своих подзадач;

3) Работа с памятью стала медленнее, чем выполнение инструкций процессора, в результате чего потребовались кеши;

4) У подзадач могут быть какие-то общие данные, что влечёт необходимость обеспечивать когерентность кешей

5) Есть trade-off между производительностью и соответствием того, как исполняется код, интуитивным предположениям;

6) Например, reordering-и, появляющиеся в MESI при добавлении invalidate queue и write buffers;

7) Разработчики процессоров не могут знать заранее, когда reordering допустим, а когда нет. Это должны решать разработчики софта. Понятие memory model. Пример с memory barriers в терминах MESI.

8) Причём тут java? Текущие абстракции.

9) Зачем нужны более высокоуровневые инструменты из JMM: атомарность, взаимное исключение, синхронизация потоков.

О докладчике

Глеб Смирнов. Увлекается многопоточностью в java с 2009 года. Вёл разработку серверных приложений с высокой степенью параллелизма, включая платформу для высокочастотной алгоритмической торговли. Последние полтора года работает в Яндексе.