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 содержит null-элемент, будет вызвано исключение NullPointerException. В этом случае некоторые не-null элементы в массиве могут быть обработаны до аномального завершения метода. Какие это элементы (если есть) зависит от реализации.

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

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

Следующие эффекты наблюдаются для каждого отдельного объекта вызова S:

• Создаётся новая volatile переменная V, и записывается текущим потоком. Как определено в JMM, эта запись является глобальным событием синхронизации.
• Как обычно с локальным упорядочением событий записи, каждое действие, уже выполненное текущим потоком, считается происходящим до volatile записи в V. (В некоторых реализациях это означает, что текущий поток выполняет глобальную операцию release.)
• В частности, запись в текущий целевой метод объекта 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.