Слушатели Java должны быть удалены? (В целом)

В ссылочном графике существует цикл. Ссылки B и ссылки B A. Сборщик "мусора" будет обнаруживать циклы и видеть, когда не будет никаких внешних ссылок на A и B, и тогда не соберут обоих.

Попытка использовать финализатор здесь является неправильной. Если B уничтожается, ссылка на A также удаляется.

оператор: "Предположите, что экземпляр будет совместно использован с некоторыми другими объектами также и переживет экземпляр B". является неправильным. Единственный путь, который произойдет, состоит в том, если слушатель явно удален из куда-нибудь кроме финализатора. Если ссылки на A розданы, который будет подразумевать ссылку на B, и B не будет собран "мусор", потому что существуют внешние ссылки на цикл A-B.

Дальнейшее обновление:

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

class A {
    void addListener(Listener obj);
    void removeListener(Listener obj);
}

class B {
    private static class InnerListener implements Listener {
        private WeakReference m_owner;
        private WeakReference m_source;

        InnerListener(B owner, A source) {
            m_owner = new WeakReference(owner);
            m_source = new WeakReference(source);
        }

        void listen() {
            // Handling reentrancy on this function left as an excercise.
            B b = (B)m_owner.get();
            if (b == null) {
                if (m_source != null) {
                    A a = (A) m_source.get();
                    if (a != null) {
                        a.removeListener(this);
                        m_source = null;
                    }
                }

                return;
            }
            ...
        }
    }

    private A a;

    B() {
        a = new A();
        a.addListener(new InnerListener(this, a));
    }
}

Мог быть далее обобщен в случае необходимости через несколько классов.

Если Вы добавили B как слушатель A, и A предназначен для переживания B, завершить запрос B никогда не будут называть, потому что существует экземпляр B в A, таким образом, это никогда не будет собираться "мусор". Вы могли обойти это путем хранения ссылки на B в как WeakReference (который не считают ссылкой во время набора гаража), но было бы лучше явно вычеркнуть из списка B от, когда Вам больше не нужен он.

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

Мое понимание GC - то, что, пока removeListener метод не называют, класс A будет поддерживать ссылку на слушателя и таким образом, это не будет кандидатом на очистку GC (и следовательно завершит, не будет назван).

Необходимо происходить из C++ или некоторого другого языка, где люди реализуют деструкторы. В Java Вы не делаете этого. Вы не переопределяете, завершают, если Вы действительно не знаете то, что Вы делаете. Через 10 лет я никогда не должен был делать это, и я все еще не могу думать о серьезном основании, которое потребовало бы, чтобы я сделал это.

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

Желание действительно поддерживает B через анонимный экземпляр.

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

Хранения ссылка на B через анонимный экземпляр в неявно используемом анонимным типом создается. Это означает, что B не будет освобожден, пока removeListener не называют, и таким образом B завершают, не будет назван.

, Когда A уничтожается, это - анонимная ссылка на B, будет также B уничтоженное открытие путь к B быть освобожденным.

, Но так как B содержит ссылку на это, никогда не происходит. Это походит на вопросы проектирования - если A имеет вызовы слушатель, почему Вам нужен B, чтобы также содержать ссылку на A? Почему бы не передать, который выполнил вызов слушателю при необходимости?

В Вашей ситуации единственная сборка "мусора" "проблема" - то, что экземпляры B не будут собраны "мусор", в то время как существуют твердые ссылки на общий экземпляр A. Это - то, как сборка "мусора" предположила для работы в Java/.NET. Теперь, если Вам не нравится то, что экземпляры B не собраны "мусор" ранее, необходимо ли спросить себя в том, какая точка Вы хотите, чтобы они прекратили слушать события от A? Как только у Вас есть ответ, Вы будете знать, как зафиксировать дизайн.

Когда B собран "мусор", он должен позволить быть собранным "мусор" также, и поэтому любые ссылки в также. Вы не должны явно удалять ссылки в A.

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

Как может A переживать B?:

Использование В качестве примера B и A:

public static main(args) {
    B myB = new B();
    myB = null;
}

Поведение я ожидал бы:

GC удалит myB, и в myB экземпляре должен был только сослаться к экземпляр, таким образом, это будет удалено также. Со всеми их присвоенными слушателями?

Сделал Вас, возможно, имейте в виду:

class B {
    private A a;
    B(A a) {
        this.a = a;
        a.addListener(new Listener() {
            void listen() {}
        }
}

С использованием:

public static main(args) {
    A myA = new A();
    B myB = new B(myA);
    myB = null;
}

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

Здание, что @Alexander, сказанный об удалении себя как слушатель:

, Если нет некоторый неопровержимый довод не к, одна вещь, я учился от своих коллег, то, что вместо того, чтобы делать анонимного внутреннего Слушателя, и должным быть сохранить его в переменной, заставляют B реализовать Слушателя, и затем B может удалить себя, когда это должно с a.removeListener(this)

Желание действительно мешает B собираться "мусор" в Вас, используют стандартные ссылки для хранения слушателей. Кроме того, когда Вы ведете списки слушателей вместо того, чтобы определить новый ArrayList< ListenerType> (); Вы могли сделать что-то как новый ArrayList< WeakReference< ListenerType> > ();

Путем обертывания объекта в weakReference можно помешать ему продлевать жизнь объекта.

Это только работает, конечно, если Вы пишете класс, который содержит слушателей