Возможные утечки памяти на внутреннем конечном объекте (Java) - PullRequest
0 голосов
/ 21 января 2019

Я немного обыскал эти случаи и не смог найти удовлетворительного ответа, так что я здесь. Примечание: Это будет пример кода, поскольку я не могу опубликовать что-либо из исходного кода, поскольку он классифицирован.

Предположим, что в этом случае:

public class Instance
{
    private ClassMember classMember = new ClassMember();

    // Imagine this method is called once as like the main method of apps.
    public static void main(String[] args)
    {
        new Instance().myMethod();
    }

    private void myMethod()
    {
        final SomeObject object = new SomeObject();

        // This is the class member that is declared at top of the class.
        classMember.addCallback(new Callback()
        {
            @Override
            public void onCall(boolean result)
            {
                object.setResult(result).report(); // I'm done with this object, want to release it.

                // After this call, will there be a leak due to "SomeObject object"?
                // If so, how can this be prevented from happening?
            }
        });

        object.makeCall(classMember); // asynchronous task such as Internet connections.
    }
}

Давайте объясним переменные и классы:

  • Экземпляр - это предположительно основной класс, который содержит метод main.Считайте этот метод вызванным из другого класса, он определен для простоты.
  • ClassMember - это класс, который обрабатывает обратные вызовы интернет-соединения.Будет использоваться с SomeObject .
  • SomeObject - это объект, который должен быть создан в методе как final, чтобы использовать его внутри метода "addCallback".Метод «makeCall» является асинхронным, который может быть завершен или нет, например, создание интернет-соединений.

Теперь, что мне интересно, это может быть утечка памяти из-за «конечного объекта SomeObject», и яхотите предотвратить это, выпуская его после получения обратного вызова в методе "onCall ()", например, установив его в null.Но поскольку это окончательно, я не могу этого сделать, поэтому я ищу альтернативу.

Есть предложения?Спасибо.

Ответы [ 2 ]

0 голосов
/ 21 января 2019

Учитывая предоставленный код, утечка памяти отсутствует из-за того, что someObject это final или нет.Экземпляр используется только в области действия myMethod, и внешние ссылки не даются (по крайней мере, за пределами Instance).То есть GC заметит, что его можно собрать после того, как myMethod или асинхронный makeCall завершится.

Единственное, что меня беспокоит, это то, что вы упомянули, что вызов makeCall может незакончить на всех.Вы должны иметь в виду, что все ресурсы в контексте этого вызова будут недоступны до тех пор, пока вызов не будет завершен.То есть экземпляры Instance, ClassMember и SomeObject останутся в куче на время makeCall.

Конечно, если вы сделаете что-то глупое в makeCall, вы получитетечь так или иначе.

ОБНОВЛЕНИЕ:

Как указал @Seelenvirtuose, ваш пример кода может быть немного упрощен, что приведет к ложным предположениям.Мой ответ верен, если экземпляры Instance используются так же, как они используются в предоставленном коде - как одноразовые объекты.Вы должны знать, что при каждом вызове myMethod и каждом вызове classMember.addCallback, classMember будет получать ссылку на экземпляр object, созданный в myMethod.То есть ссылки на object будут накапливаться в classMember и, таким образом, в соответствующем случае Instance - это то, что я имел в виду с моим добавлением , по крайней мере, за пределами Instance.Учитывая предоставленный код, вы можете столкнуться с утечкой памяти или нет.Все зависит от использования Instance в вашем реальном сценарии.

0 голосов
/ 21 января 2019

Конечное состояние не помешает его сборке мусора. Если обратный вызов выполнен и объект не содержится в classMember (из-за какого-то списка обработчиков или чего-то подобного), счетчик ссылок уменьшается до 0 и, таким образом, он будет собирать мусор (в какое-то время).

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