Блог

Допустим, у меня есть класс X с двумя переменными.

 class X {
    Integer a;
    Y b;
    Integer c;
}
 

Класс Y

 class Y {
    Integer y1;
    String y2;
}
 

Скажем, у нас есть 4 потока: T1, T2, T3 и T4.

T1 работает a , T2 работает b.y1 (делает что-то вроде x.getB().setY1() ), T3 работает b.y2 , и T4 работает c .

Я не буду читать ни одно из «самых глубоких» значений ( a, y1, y2, c ) в любом потоке, пока все они не будут выполнены (однако T2 и T3 сделают x.getB() это).

Столкнусь ли я с какой-либо из типичных проблем, связанных с многопоточностью?

Мои вопросы

1. Я думаю, что я не мог бы столкнуться с каким-либо условием гонки в отношении a и c, учитывая, что они не читаются потоками, отличными от «их» потока. Правильно ли это рассуждение?
2. Как насчет x.getB() T2 и T3?
3. Как насчет кэширования процессорами в многоядерной среде? Кэшируют ли они весь объект? Или они кэшируют только то поле, которое они изменяют? Или они кэшируют все это, но обновляют только поле, которое они изменили?
4. Они даже распознают объекты и поля? Или они просто работают с кусками памяти? В этом случае Java сообщает им адрес памяти, который им нужно будет кэшировать?

Когда процессоры согласовывают свой кэш с основной памятью после завершения обработки, обновляют ли они только тот фрагмент памяти, который они изменили, или они перезаписывают основную память всем блоком памяти, который они кэшировали?

Например, скажем, изначально и a, и c имеют значения a = 1 , и c = 1 . P1 и P4 кэшируют эти значения ( a=1 и c=1 ). T1 изменяет его на a = 2 , T4 изменяет на c = 2 .

Теперь значения в кэше C1 равны a=2, c=1 ; в C2, a=1, c=2 .

Итак, при обратной записи в основную память, скажем, сначала завершается P1, а затем обновляется основная память. Итак, теперь значения a=2, c=1 .

Теперь, когда P4 завершается, обновляет ли он значение only c , потому что оно только изменилось c ? Или он просто перезаписывает основную память значением в своем кэше, создавая a=1, c=2 ?

Или они просто кэшируют значения, которые они будут читать или записывать, то есть T1 никогда не будет кэшировать значение c , а T4 никогда не будет кэшировать значение a .

Столкнусь ли я с какой-либо из типичных проблем, связанных с многопоточностью?

Вы только читаете, поэтому, конечно, нет. Ваш вопрос даже не актуален. Модель памяти Java описывает, как изменения в полях распространяются на другие потоки. Сначала это требует фактических изменений.

обновляют ли они только тот фрагмент памяти, который они изменили, или они перезаписывают основную память всем блоком памяти, который они кэшировали?

Только то, что они изменили.

Как насчет кэширования процессорами в многоядерной среде? Кэшируют ли они весь объект? Или они кэшируют только то поле, которое они изменяют?

Ваш вопрос не имеет смысла. Вы вообще не можете помещать объекты в поля или переменные, это невозможно. Единственное, что вы можете вставить в поля / переменные / параметры, — это ссылки на объекты. В String x = "foo" , вы не вставили «foo» x . «foo» живет где-то в куче. Вы убедились, что он существует в куче, и вы назначили ссылку на него x . Эта ссылка довольно простая, обычно 64-разрядная и атомарная.

Единственное, что вы можете разделить между потоками, где актуальны обновления, — это поля. методы не могут быть изменены (вы не можете изменить метод экземпляра чего-либо; java не похожа на python или javascript, вы не можете написать someRef.flibbledyboo = thingie; , где ‘flibbledyboo’ — это то, что вы только что придумали. Локальные переменные (которые включают параметры) не могут быть совместно использованы с другими потоками; java передается по значению во всех вещах, поэтому, если вы это сделаете, внутри метода someOtherMethod(variable); вы передаете копию, указывая на «что произойдет, если я изменю свою переменную, и SomeOtherMethod передаст ее другимдругой поток?’ не имеет значения.

Казалось бы, вы можете совместно использовать локальный var с потоком, если создаете лямбда- или локальный класс, но java откажется компилировать это, если var не является окончательным или фактически окончательным. Если это (фактически) окончательное, точка является спорной — ее нельзя изменить, поэтому вопрос «что произойдет, если один поток обновит это значение, когда другой поток увидит обновление» не имеет значения.

Таким образом: речь идет только о полях, а поля могут содержать только примитивные значения или ссылки. Ссылки — это простые вещи. Если вы знакомы с C, они являются указателями, но это ругательное слово, поэтому java называет их ссылками. Потайто, Потайто. То же самое.

Любое поле (будь то примитивное или ссылочное) может быть кэшировано любым потоком или нет, по выбору дилера. Они могут «синхронизировать» это обратно в основную память в любое время, когда пожелают. Если ваш код изменяет способ выполнения в зависимости от этого, вы написали труднодоступную ошибку. Старайтесь этого не делать 🙂

Они даже распознают объекты и поля? Или они просто работают с кусками памяти?

Опять же бессмысленный вопрос, согласно предыдущему пункту: это значения, которые вы ищете: примитивы и ссылки. Вот что такое JMM (а не «куски памяти»). объекты не могут находиться в полях. Только ссылки. Ссылка идет на объект, но этот объект — просто еще один пакет полей. Это поля до самого низа.

Представьте, что поток A делает: foo.getX().setY() и поток B делает: foo.getX().getY() . предполагая foo , что никогда не меняется, то, по-видимому foo.getX() , также никогда не меняется. Это всего лишь ссылка, а ‘.’ — это java-ese для: следуйте ей, найдите там пакет полей и работайте с ними. Итак, оба потока находят один и тот же объект и поля с сумками, которые есть на самом деле. Теперь поток A изменил одно из найденных там полей, а B читает одно из них. Это проблема — это поля. потоки могут кэшировать их, выбор дилера. Вам необходимо установить отношения HB / HA, или вы написали здесь ошибку.

Теперь, когда P4 завершается, обновляет ли он значение только c, потому что он изменил только c? Или он просто перезаписывает основную память значением в своем кэше, делая a = 1, c = 2?

Нет; но это не кажется особенно актуальным. Несвязанный поток без отношения HBHA (происходит до / после) может юридически соблюдать a = 1 / c = 1, a = 2 / c = 1 или a = 1 / c = 2. Однако, если они каким-то образом наблюдали a = 2 / c = 1, то впоследствии они будут продолжать наблюдать a = 2. Он не вернется к 1 из-за перезаписи стиля «перезаписать весь блок».

Или они просто кэшируют значения, которые они будут читать или записывать, то есть T1 никогда не будет кэшировать значение c, а T4 никогда не будет кэшировать значение a .

Выбор дилера. JMM лучше всего понимать следующим образом:

Каждый раз, когда какой-либо поток когда-либо обновляет какое-либо поле (а значения всегда являются примитивами или ссылками), он переворачивает злую монету. Если при перевороте выпадают заголовки, он обновляет это значение в своем локальном кэше и не «распространяет» его на любой другой код, который взаимодействует с этим полем, если только этот поток не имеет установленного правила HBHA. В tails он обновляет произвольный выбор кэшей других потоков.

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

Монета — зло: это не выстрел 50/50. Фактически, сегодня на вашем ноутбуке при написании этого кода каждый раз появляются хвосты — даже если вы повторяете тест 1 миллион раз. На вашем сервере CI такая же сделка. хвосты. Затем в производстве — хвосты, каждый раз. Затем на следующей неделе, когда придет этот важный клиент, и вы покажете демонстрацию? Много головок.

Таким образом:

• Трудно обнаружить, что вы создали код, выполнение которого зависит от coinflip.
• Тем не менее, если вы пишете код, выполнение которого зависит от flip, вы потерпели неудачу. Это ошибка.

Обычно решение состоит в том, чтобы полностью забыть о потоках таким образом и выполнять межпоточное взаимодействие либо «по каналам», либо заранее и впоследствии.

Канал связи

Существуют системы каналов связи, которые подходят гораздо лучше. Например, базы данных: не обновлять поля; отправлять запросы к БД. используйте transactions и isolationlevel.СЕРИАЛИЗУЕМЫЙ, с фреймворками, поддерживающими RetryException (например, JDBI или JOOQ — не создавайте свой собственный, не используйте JDBC напрямую). Вы получаете точный контроль над каналом данных.

Другими вариантами являются шины сообщений, такие как rabbitmq.

заранее / после

Используйте такие фреймворки, как fork / join и friends, или что-нибудь еще, что, например, следует модели map / reduce. Они настраивают некоторые структуры данных, только затем запускают ваш поток (или, скорее, у них есть пул em, и они будут выполнять ваш код в одном потоке пула, передавая вам структуру данных). Ваш код просто просматривает эту структуру данных, а затем возвращает что-то. Он вообще не затрагивает никаких других полей. Фреймворк создает данные и интегрирует то, что вы возвращаете. Тогда доверяйте фреймворку; у них, вероятно, нет ошибок модели памяти.

Я действительно хочу изменять потоки в многопоточной среде.

Господи, здесь драконы.

Если необходимо, найдите «происходит-до / происходит-после»: для любых 2 строк кода, если существует связь HB / HA (например, согласно правилам JMM, одна строка гарантированно произошла раньше другой), тогда любые обновления полей предыдущей строкивызвавший гарантированно будет виден на более поздней полосе — никаких злых переворотов.

Очень краткий обзор:

• В пределах одного потока любая более поздняя выполняемая строка «выполняется после». Это очевидный факт — java является обязательным. Что вы можете наблюдать из кода, так это то, что каждая строка в одном потоке выполняется одна за другой.
• синхронизированный: когда у вас есть 2 потока, и один поток попадает в блок кода, защищенный synchronized(X) , а затем выходит из этого блока, а другой поток позже входит в блок, защищенный синхронизацией по той же ссылке, тогда точка выхода потока A гарантированно «произойдет до» точки входа B: независимоA, измененный внутри, вы увидите в B, гарантировано.
• volatile — аналогичные правила, но volatile сложен.
• Запуск потока: someThread.start() имеет связь HB / HA с кодом в этом потоке.
• Конструкторы и настройка конечных полей более или менее гарантированно работают (настройка поля «выполняется до» возврата конструктора, даже если затем вы передаете объект ref, который вы получили, вызвав этот конструктор в другой поток без защиты HB / HA, и они каким-то образом получают его, потому что злая монета приземлилась орлами).
• система загрузки классов никогда не будет загружать один и тот же класс дважды в одном и том же загрузчике классов. Это очень быстрый и простой способ создания безопасных одиночек.

Если какой-то код X обновляет поле, а какой-то другой код Y считывает это поле, а X и Y не имеют отношения HB / HA, вы полностью закрыты. Вы написали ошибку, и ее будет довольно сложно проверить, и тест не будет надежным.

Ваш вопрос затрагивает ряд интересных тем. Я постараюсь переформулировать ваши вопросы и ответить на них по порядку.

На ваш первый вопрос: если разные потоки изменяют только разные объекты, может ли это создавать проблемы с согласованностью?

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

Однако, если потоку необходимо прочитать значение переменной, которая могла быть изменена другим потоком, вам необходимо ввести некоторую синхронизацию, чтобы изменение этой переменной происходило до того, как ее прочитает первый поток (синхронизированный блок / доступ к изменяемой переменной / семафоры и т. Д.). Я не могу рекомендовать достаточно эту статью, исправляющую модель памяти Java.

На ваш второй вопрос:

Тот же ответ на ваш первый вопрос: пока ни один поток не изменяет член b вашего X экземпляра, причин для беспокойства нет; оба потока T2 и T3 получат один и тот же объект.

На ваш третий и четвертый вопрос, как насчет согласованности кэша?

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

Однако, если в элементах достаточно конфликтов, вы можете столкнуться со снижением производительности. К счастью, вы можете уменьшить это влияние, используя @Contended аннотацию к элементам, которые создают проблемы, чтобы указать виртуальной машине Java, что они должны быть размещены в разных строках кэша.