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

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

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

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

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

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

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

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

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