Класс MutableCallSite

public MutableCallSite(MethodType type)

Создаёт пустой объект вызова с заданным типом метода. Изначальная цель устанавливается в метод-обработчик данного типа, который будет выбрасывать IllegalStateException, если его вызвать.

Тип вызова устанавливается постоянно и соответствует заданному типу.

Перед тем, как этот CallSite объект возвращается из метода инициализации или вызывается каким-либо другим способом, ему обычно предоставляется более полезный целевой метод, через вызов setTarget.

public MutableCallSite(MethodHandle target)

Создаёт объект вызова с начальным методом-обработчиком. Тип вызова постоянно устанавливается в тип начального целевого метода.

public final MethodHandle getTarget()

Возвращает целевой метод вызова, который ведёт себя как обычное поле объекта MutableCallSite.

Взаимодействия getTarget с памятью аналогичны чтению из обычной переменной, такой как элемент массива или не-volatile, не-final поле.

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

public void setTarget(MethodHandle newTarget)

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

Взаимодействия с памятью аналогичны записи в обычную переменную, такую как элемент массива или не-volatile, не-final поле.

В частности, несвязанные потоки могут не видеть обновлённого целевого значения до тех пор, пока они не выполнят чтение из памяти. Более сильные гарантии можно создать, поместив соответствующие операции в метод инициализации и/или целевые методы, используемые в данном вызове.

public final MethodHandle dynamicInvoker()

Создаёт метод-обработчик, эквивалентный инструкции invokedynamic, которая была связана с этим вызовом.

Этот метод эквивалентен следующему коду:

 MethodHandle getTarget, invoker, result;
 getTarget = MethodHandles.publicLookup().bind(this, "getTarget", MethodType.methodType(MethodHandle.class));
 invoker = MethodHandles.exactInvoker(this.type());
 result = MethodHandles.foldArguments(invoker, getTarget)
 

public static void syncAll(MutableCallSite[] sites)

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

Эта операция не отменяет вызовы, которые уже начались со старым значением цели. (Java поддерживает только путешествия вперёд во времени.)

Общий эффект заключается в том, чтобы заставить все будущие чтецы каждой цели вызова принять последнее сохранённое значение. («Последнее» определяется относительно syncAll самого.) И наоборот, вызов syncAll может заблокироваться до тех пор, пока все читатели не откажутся (как-то) от всех предыдущих версий цели каждого вызова.

Чтобы избежать гонок, вызовы setTarget и syncAll в целом следует выполнять под какой-либо формой взаимного исключения. Обратите внимание, что потоки-читатели могут наблюдать обновлённое значение цели уже в момент вызова setTarget , который установил значение (и до вызова syncAll, подтверждающего значение). С другой стороны, потоки-читатели могут наблюдать предыдущие версии цели до того, как вызов syncAll вернётся (и после вызова setTarget, который пытается передать обновлённую версию).

Эта операция, вероятно, будет дорогостоящей и должна использоваться экономно. Если возможно, она должна быть буферизирована для пакетной обработки набора вызовов.

Если sites содержит нулевой элемент, будет выброшено исключение NullPointerException. В этом случае некоторые ненулевые элементы массива могут быть обработаны до аномального завершения метода. Какие именно элементы это будут (если таковые имеются) — зависит от реализации.

Подробности модели памяти Java

С точки зрения модели памяти Java, эта операция выполняет действие синхронизации, которое по своему эффекту сопоставимо с записью переменной volatile текущим потоком и последующим чтением этой переменной volatile всеми другими потоками, которые могут получить доступ к одному из затронутых вызовов.

Видимые эффекты для каждого отдельного вызова S:

• Создаётся новая переменная volatile V, и записывается текущим потоком. Как определено в JMM, эта запись является глобальным событием синхронизации.
• Как обычно для локального упорядочивания событий записи, каждое действие, уже выполненное текущим потоком, считается предшествующим записи volatile в V. (В некоторых реализациях это означает, что текущий поток выполняет глобальную операцию освобождения.)
• В частности, запись в текущее значение цели вызова S считается предшествующей записи volatile в V.
• Запись volatile в V размещается (специфичным для реализации способом) в глобальном порядке синхронизации.
• Рассмотрим произвольный поток T (кроме текущего). Если T выполняет действие синхронизации A после записи volatile в V (в глобальном порядке синхронизации), то он должен увидеть либо текущее значение цели вызова S, либо более позднюю запись в неё, если он выполняет чтение цели S. (Это ограничение называется «согласованностью порядка синхронизации».)
• JMM специально разрешает оптимизирующим компиляторам исключать чтения или записи переменных, которые известны как бесполезные. Такие исключённые чтения и записи не влияют на отношение happens-before. Несмотря на это, volatile V не будет исключена, даже если её записанное значение неопределённо, а считанное значение не используется.

Из-за последнего пункта, реализация ведет себя так, как будто поток T выполняет чтение volatile V сразу после своего действия A. В локальном порядке действий в T, это чтение происходит до любого будущего чтения значения цели вызова S. Это как если бы реализация произвольно выбрала чтение значения цели S потоком T и принудительно сделала чтение V предшествующим ему, тем самым гарантируя передачу нового значения цели.

До тех пор, пока соблюдаются ограничения модели памяти Java, реализации могут задерживать завершение операции syncAll , в то время как другие потоки (T выше) продолжают использовать предыдущие значения цели S. Однако реализации (как всегда) рекомендуется избегать блокировок, и в конечном счёте потребовать, чтобы все потоки учли обновлённое значение цели.

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

Примечание по реализации: Простые реализации MutableCallSite могут использовать переменную volatile для значения цели объекта mutable call site. В такой реализации метод syncAll может быть бесполезным, и тем не менее, он будет соответствовать документированному выше поведению JMM.