Фантомные ссылочные объекты
Я думаю, что это также может иметь какое-то отношение к неожиданному поведению, которое может возникнуть из-за неявного предоставления лексического имени тому, что вы можете ожидать анонимной функцией.
Скажем, например, кто-то понял функцию стрелки:
(x) => x+2;
Чтобы иметь регулярную функцию, эквивалентную:
function(x) {
return x+2;
}
Было бы довольно легко ожидать этот код:
let foo = (x) => x+2;
Чтобы быть эквивалентом:
let foo = function(x) {
return x+2;
}
Если функция остается анонимной и неспособна ссылаться на себя, чтобы делать такие вещи, как рекурсия.
Итак, если тогда, в нашем блаженном невежестве, у нас было что-то вроде этого:
let foo = (x) => (x<2) ? foo(2) : "foo(1)? I should be a reference error";
console.log(foo(1));
Он успешно выполнялся, потому что эта функция явно не была анонимной:
let foo = function foo(x) {
return (x<2) ? foo(2) : "foo(1)? I should be a reference error";
}
Это может потенциально усугубиться тем фактом, что в других ситуациях, когда Babel неявно добавляет имя анонимным функциям (что, на мой взгляд, фактически является побочным эффектом поддержки имен неявных функций, в первую очередь, хотя Я мог ошибаться в этом), они правильно обрабатывают любые случаи краев и бросают опорные ошибки там, где вы ожидаете.
Например:
let foo = {
bar: function() {}
}
// Will surprisingly transpile to..
var foo = {
bar: function bar() {}
};
// But doing something like:
var foo = {
bar: function(x) {
return (x<2) ? bar(2) : 'Whats happening!?';
}
}
console.log(foo.bar(1));
// Will correctly cause a ReferenceError: bar is not defined
Вы можете проверить «скомпилированный просмотр» на этом быстром DEMO , чтобы увидеть, как Babel фактически транслирует, чтобы поддерживать поведение анонимной функции.
Короче говоря, быть явным с тем, что вы делаете, - это, как правило, хорошая идея, потому что вы точно знаете, чего ожидать от вашего кода. Отказ от использования неявных имен функций, скорее всего, является стилистическим выбором в поддержку этого, а также остается кратким и простым.
И, вероятно, подъем. Но эй, веселая прогулка.
4 ответа
Редактирование, так как я имею, неправильно понимает вопрос сначала:
Заключенный в кавычки отсюда http://www.memorymanagement.org/glossary/p.html:
Спецификация Java говорит, что фантомная ссылка не очищена, когда ссылочный объект ставится в очередь, но на самом деле, нет никакого пути на языке, чтобы сказать, было ли это сделано или нет. В некоторых реализациях JNI слабые глобальные ссылки более слабы, чем фантомные ссылки и позволяют получать доступ к фантомным достижимым объектам.
Но я не нашел никакие другие ссылки, которые скажут то же.
Я думаю, что идея состоит в том, чтобы позволить другим объектам сделать дополнительную очистку выше и вне того, что делает исходный объект. Например, если исходный объект не может быть расширен для реализации некоторого материала завершения, можно использовать фантомные ссылки.
Большая проблема состоит в том, что JVM не делает гарантии, что объект будет когда-либо завершаться, и я не принимаю следовательно гарантии, что фантомные ссылки добираются, чтобы сделать их вещь постзавершение.
Фантомные ссылки могут использоваться для выполнения действий перед сборкой "мусора", таких как освобождение ресурсов. Вместо этого люди обычно используют завершение () метод для этого, которое не является хорошей идеей. Финализаторы оказывают ужасное влияние на производительность сборщика "мусора" и могут повредить целостность данных Вашего приложения, если Вы не очень осторожны, так как "финализатор" вызывается в случайном потоке в случайное время.
В конструкторе фантомной ссылки Вы указываете ReferenceQueue, где фантомные ссылки ставятся в очередь, после того как ссылочные объекты становятся "достижимым фантомом". Фантомные достижимые средства, недостижимые кроме через фантомную ссылку. Первоначально запутывающая вещь состоит в том, что, хотя фантомная ссылка продолжает содержать ссылочный объект в частном поле (в отличие от мягких или слабых ссылок), его getReference () метод всегда возвращает пустой указатель. Это - то, так, чтобы Вы не могли сделать объект решительно достижимым снова.
Время от времени можно опросить ReferenceQueue и проверить, существуют ли какие-либо новые PhantomReferences, ссылочные объекты которых стали достижимым фантомом. Для сможения к к чему-либо полезному можно, например, получить класс из java.lang.ref. PhantomReference, что ссылочные ресурсы, которые должны быть освобождены перед сборкой "мусора". Ссылочный объект только собран "мусор", после того как фантомная ссылка становится недостижимой сама.
http://www.javalobby.org/java/forums/m91822870.html#91822413
Это может позволить, у Вас два есть фантомные кэши, которые очень эффективны в управлении памятью. Проще говоря, если у Вас есть огромные объекты, которые являются дорогими для создания, но редко используемый, можно использовать фантомный кэш, чтобы сослаться на них и быть уверенными, что они не поднимают память, которая более ценна. При использовании регулярных ссылок, необходимо быть, вручную удостоверяются, что нет никаких ссылок, оставленных объекту. Можно обсудить то же о любом объекте, но Вы не должны вручную управлять ссылками в своем фантомном кэше. Просто должны быть осторожными, чтобы проверить, были ли они собраны или нет.
Также можно использовать платформу (т.е. фабрика), где ссылки даны как фантомные ссылки. Это полезно, если объекты - многие и недолгий (т.е. используемый и затем склонный). Очень удобный для очистки памяти, если у Вас есть неаккуратные программисты, которые думают, сборка "мусора" является волшебной.