интервьюер: я помню, как спросил, почему модель памяти Java была там в прошлый раз
интервьюер: Я помню, что ваш окончательный ответ таков: чтобы скрыть различные различия между аппаратным и операционным доступом к памяти, Java предлагает спецификацию «Модель памяти Java», которая гарантирует, что Java-программы могут последовательно обращаться к памяти на различных платформах.
Кандидат:Да, это так
интервьюер:В противном случае, вы снова сегодня, чтобы сказать что-то о содержании модели памяти Java, где край воспевать?
Кандидат: Ну, прежде чем говорить об этом, я должен подчеркнуть: модель памяти Java — это «спецификация», и виртуальная машина Java реализует эту спецификацию.
Кандидат: Основное содержание модели памяти Java, я лично считаю, это следующие части
Кандидат: 1. Абстрактная структура модели памяти Java.
Кандидат: 2. правило "случиться до"
Кандидат: 3. Обсуждение семантики энергозависимой памяти (я объясню это позже)
интервьюер:Так почему бы вам не начать с первого пункта? Давайте поговорим об абстрактной структуре модели памяти Java?
Кандидат: Эм. Модель памяти Java определяет спецификацию потоков Java для взаимодействия с данными в памяти.
Кандидат: «общие переменные» между потоками хранятся в «основной памяти», каждый поток имеет свою собственную частную «локальную память», а «локальная память» хранит копию потока для чтения/записи общих переменных.
Кандидат: Локальная память — это абстракция модели памяти Java, а не реальная.
Кандидат: Кстати, нарисуй картинку, ты поймешь после прочтения картинки.
Кандидат: Модель памяти Java предусматривает, что все операции над переменными потоками должны выполняться в «локальной памяти», а переменные «не могут напрямую читать и писать в основную память»
Кандидат: модель памяти Java определяет 8 операций для выполнения того, «как переменные передаются из основной памяти в локальную память и как переменные переходят из локальной памяти в основную память».
Кандидат: соответственно операции чтения/загрузки/использования/назначения/хранения/записи/блокировки/разблокировки
Кандидат: Ввиду того, что операций много 8, одно чтение и запись переменной перекрывает эти операции.Я нарисую картинку, чтобы рассказать вам об этом.
Кандидат:понятно? Это не что иное, как чтение и запись с использованием различных операций (:
интервьюер:Понятно, очень просто, что дальше сказать случилось-прежде?
Кандидат:хорошо(:
Кандидат: Насколько я понимаю, "случиться до" на самом деле является набором "правил". Модель памяти Java определяет этот набор правил для описания «видимости» памяти «между операциями».
Кандидат: В прошлый раз, когда я говорил о "перестановке инструкций", упоминалось, что существуют проблемы перестановки инструкций на уровне процессора и компилятора.
Кандидат: Хотя перестановка инструкций может повысить эффективность работы, в параллельном программировании мы также надеемся, что «результат программы» может быть нами проконтролирован с учетом «эффективности».
Кандидат: Грубо говоря: в некоторых важных сценариях эту группу операций нельзя переупорядочить, "результат предыдущей операции должен быть виден последующим операциям".
интервьюер: Эм…
Кандидат: Итак, модель памяти Java предлагает набор правил для «случись-до».Всего 8 правил.
Кандидат: Например, транзитивность, правила volatile-переменных, правила порядка программ, правила блокировки монитора... (просто посмотрите на смысл правил, это не сложно)
Кандидат: Просто помните, с правилами «случиться до». Пока код, который мы пишем, соответствует этим правилам, результат предыдущей операции виден последующим операциям, и переупорядочение не произойдет.
интервьюер:Я понимаю, что ты имеешь в виду
интервьюер:Тогда, наконец, сказать изменчивый?
Кандидат: Ну, volatile — это ключевое слово в Java.
Кандидат: Почему в модели памяти Java часто упоминается ключевое слово volatile?Я думаю, это в основном ее характеристики: видимость и упорядоченность (переупорядочивание запрещено)
Кандидат: Спецификация модели памяти Java в значительной степени решает проблемы видимости и порядка.
интервьюер:Затем вы рассказываете о его принципе, как ключевое слово volatile достигает видимости и упорядоченности.
Кандидат: Модель памяти Java. Чтобы реализовать изменчивый порядок и видимость, определена «Спецификация» 4 барьеров памяти, названных Loadload / LoadStore / StoreLoad / Storestore.
Кандидат: Возвращаясь к volatile, грубо говоря, добавление «барьера памяти» до и после volatile делает невозможным переупорядочивание компилятором и ЦП, в результате чего порядок и запись volatile-переменных видны другим потокам.
Кандидат: Модель памяти Java определяет спецификацию, поэтому виртуальная машина Java должна быть реализована, верно?
интервьюер: Эм…
Кандидат: Я уже видел реализацию виртуальной машины Hotspot.На уровне "сборки" она фактически реализуется через инструкцию префикса Lock, а не различные инструкции забора (основная причина - простота. Поскольку большинство платформ поддерживают инструкцию блокировки, а инструкция забора для платформы x86).
КандидатИнструкция :lock гарантирует, что переупорядочивание ЦП и компилятора запрещено (гарантируя упорядоченность), что инструкции, записанные ЦП в ядро, могут немедленно вступить в силу, а данные кэша других ядер становятся недействительными (гарантируется видимость).
интервьюер:Затем вы упомянули об этом, я хочу спросить, какова связь между volatile и протоколом MESI?
Кандидат: Они не связаны напрямую.
Кандидат: Модель памяти Java фокусируется на уровне языка программирования, который представляет собой многомерную абстракцию. MESI — это протокол согласования кэш-памяти ЦП. Разные архитектуры ЦП отличаются друг от друга. Некоторые ЦП могут вообще не использовать протокол MESI...
Кандидат: Просто МЭСИ известный, и все берут с него пример. И MESI может быть только частью «особого случая», используемого для достижения изменчивой видимости/упорядочения (:
интервьюер: Эм…
Кандидат: Чтобы Java-программисты скрыли изложенные выше знания, они быстро начали использовать volatile-переменные.
Кандидат: определение правил volatile-переменных содержится в правилах «случается до» модели памяти Java.
Кандидат: Содержание этого правила на самом деле таково: операция записи в изменчивую переменную видна последующей операции чтения изменчивой переменной.
Кандидат: Это предусмотрено правилом «происходит до»: пока переменная объявляет ключевое слово volatile, она читается после записи, и при чтении должно быть записано значение. (видимость, упорядоченность)
интервьюер: Эм... Понял
Резюме этой статьи:
- Почему существует модель памяти Java: Чтобы скрыть различные различия между аппаратной памятью и памятью доступа операционной системы, Java предлагает спецификацию «Модель памяти Java», которая гарантирует, что программы Java могут получать согласованные результаты при доступе к памяти на различных платформах.
- Абстрактная структура модели памяти Java: «общие переменные» между потоками хранятся в «основной памяти», каждый поток имеет свою собственную частную «локальную память», а «локальная память» хранит копию потока для чтения/записи общих переменных. Все операции над переменными потоками должны выполняться в «локальной памяти», а переменные, которые «не могут напрямую читать и писать в основную память»
- правило «происходит до»: модель памяти Java предусматривает, что в некоторых сценариях (всего 8) результат предыдущей операции должен быть виден последующим операциям. Эти 8 правил становятся правилами «случись до»
- volatile: volatile — это ключевое слово Java, и измененные переменные видны и упорядочены (не будут переупорядочены). Видимость обеспечивается правилом "происходит до", а упорядочение осуществляется "барьером памяти", определенным моделью памяти Java. Фактическая виртуальная машина HotSpot реализует спецификацию модели памяти Java, а нижний уровень сборки реализуется моделью памяти Java. Инструкция блокировки.
Добро пожаловать в мой публичный аккаунт WeChat【Java3y] Давайте поговорим о Java-интервью, серия онлайн-интервьюеров постоянно обновляется!
Серия [Онлайн-интервьюер-Мобильный терминал]Продолжаем обновлять два раза в неделю!
【Онлайн-интервьюер-компьютер】СерияПродолжаем обновлять два раза в неделю!
Оригинал это не просто! ! Проси три! !