Какой ключевой принцип определяет модель памяти Java (Java Memory Model, JMM)?

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

А Happens-Before — это такой железный договор, блядь. Если операция А случилась-до операции Б, то всё, что натворила А в памяти, обязано быть видно тому, кто выполняет Б. Не «может быть», а обязано, ёпта! Это не про физический порядок на процессоре, это про юридические гарантии, которые JVM тебе даёт.

Вот смотри, классический пример, чтобы не быть идиотом:

// Общие переменные
int value = 0;
boolean flag = false;

// Поток 1 (Писатель)
value = 42;          // Операция (1)
flag = true;         // Операция (2) - запись в volatile

// Поток 2 (Читатель)
if (flag) {          // Операция (3) - чтение volatile
    // Гарантированно увидит value = 42, потому что (1) happens-before (2),
    // а (2) happens-before (3) по правилу volatile.
    System.out.println(value); // Выведет 42
}

Видишь магию? Без volatile у flag — второй поток мог бы навеки зациклиться или увидеть true, но при этом прочитать value как 0, потому что переупорядочивание операций, блядь. А как только flag — volatile, всё, пипец. Запись в него (2) — happens-before чтение из него (3). А раз (1) было до (2) в том же потоке, то и (1) happens-before (3). Вуаля, читатель гарантированно видит 42, а не какую-то случайную хуету.

Основные законы этого уголовного кодекса (JMM):

1. Монитор (synchronized). Выход из блока (unlock) happens-before последующий вход (lock) в тот же самый монитор. То есть если один мудак всё там понаписал и отпустил замок, следующий, кто его схватит, гарантированно увидит все те записи. Иначе какой смысл, блядь, в этом синхронизаторе?
2. Volatile переменные. Это священное правило, его уже разжевали. Запись happens-before чтение. Основа основ, ебать его в сраку.
3. Запуск потока. Вызов thread.start() happens-before первое действие в запущенном потоке. То есть всё, что ты настроил в основном потоке перед start(), новый поток увидит. А то что внутри — это уже его тёмные делишки.
4. Завершение потока. Все действия в потоке happen-before тот момент, когда другой поток успешно вылез из thread.join(). То есть если ты дождался конца потока через join(), тебе гарантированно откроются все его грехи в памяти.

Вот эти правила, они, блядь, и позволяют писать многопоточный код, который работает предсказуемо, а не как божья роса. Без них пришлось бы полагаться на конкретный процессор или версию JVM, а это путь в никуда, в один сплошной «а вот у меня на машине работает».