Возможные проблемы с памятью при множественной инициализации ArrayList внутри метода в java - PullRequest
Новая
       28

Возможные проблемы с памятью при множественной инициализации ArrayList внутри метода в java

1 голос
/ 18 января 2020

В настоящее время я анализирую качество кода для контроллера метода , который имеет несколько инициализаций ArrayLists следующим образом: 

public controller(Aggregate agr) {
    List<FCompound> fCompounds = new ArrayList<>();
    List<CCompound> cCompounds = new ArrayList<>();
    List<Dist> oDist = new ArrayList<>();
    List<Trans> oTrans = new ArrayList<>();

    List<CContent> cContents = new ArrayList<>();
    List<FDist> fDidst = new ArrayList<>();
    List<CDist> cDist = new ArrayList<>();
    List<FDist> efDist = new ArrayList<>();
    List<CDist> ecdist = new ArrayList<>();

    List<KList> kList = new ArrayList<>();

, что фактически являются неизменными при присвоении различным объектам ArrayList через списки, возвращаемые службами БД 

List<FCompound> fCompounds = DBservice().getAllfCompounds();
List<CCompound> cCompounds = DBservice().getAllcCompounds();
List<Dist> oDist = DBservice().getODist();
List<Trans> oTrans = DBservice().getOTrance();

List<CContent> cContents = DBservice().cContent();
List<FDist> fDidst = DBservice().getFDist();
List<CDist> cDist = DBservice().getcDist();
List<FDist> efDist = DBservice().getefDist();
List<CDist> ecdist = DBservice().getecDist();

List<KList> kList = DBservice().getKDist();
}

, почти сразу означающие, что все объекты ArrayList, созданные в первом фрагменте кода, Toast для сборки мусора

Во-первых, проблема в том, что этот метод контроллера вызывается для каждого запроса из-за плохой конструкции контроллера 1 monolithi c, который обслуживает 100% трафика приложения c, в настоящее время Я начинаю сомневаться в том, что это приведет к утечке памяти из-за меньшего пространства кучи?

Что бы обойти эту проблему, инициализировала бы списки с нулем как 

        List<FCompound> fCompounds = null;

или это ничего не изменит?

есть ли способ проанализировать пространство кучи с помощью стресс-теста для этого м енит

1 Ответ

0 голосов
/ 18 января 2020

Для анализа пространства кучи вы можете использовать visualvm. До Java 8 он был снабжен Oracle JDK8. Начиная с JDK 9, Visual VM не будет включен в Oracle JDK. Вы можете получить его от https://visualvm.github.io/download.html.

. По первому вопросу утечка памяти не произойдет из-за меньшего пространства кучи. Всякий раз, когда вы создаете объект, и на него больше нет ссылок, он будет иметь право на сборку мусора. В вашем контроллере он имеет немного инициализации массива, например, 

List<FCompound> fCompounds = new ArrayList<>();

Теперь, когда выполняется нижняя строка, над объектом arrayList можно собирать мусор. 

List<FCompound> fCompounds = DBservice().getAllfCompounds();

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

Вы можете даже инициализировать arraylist как ноль. 

List<FCompound> fCompounds = null;

Но, в этом случае, если ваша служба БД вернет ноль (я не знаю, как реализована ваша служба БД), вы можете получить исключение NullPointerException. Таким образом, чтобы использовать это и избавиться от NPE, вы можете использовать java .util.Optional при возврате чего-либо из службы БД.

...