java обход дерева

[Geksa 5]

Вопрос по обходу дерева состава изделия..

Код:

                    TCComponentBOMLine BOMLine = BOMWin.setWindowTopLine(null,mainRev,null,null);
                
                    AIFComponentContext[] children=BOMLine.getChildren();
                     for (int i=0; i<children.length; i++) {

                     }

 

таким образом получаем потомков 1 уровня.

Далее рекурсивно получаем потомков и т.д.

Но получается что массив children мы можем освободить только после того, как обойдем всё дерево.. а ведь создаются и массивы внутренних подсборок. Расходуется большой объем памяти..

Как с этим бороться?

[Солнцеворот 207]

Чисто интуитивно, вы можете удалять из чилдрена те элементы, которые больше не нужны. Получили потомков первого уровня, взяли первого из чилдрена, у него вызвали снова поиск потомков и т.д. Когда дошли до дна, собираете информацию с ветки, после чего убиваете ссылку на объект (делаете ему = null , чтобы наверняка). Приходит гарбадж коллектор и освобождает память.

[Wise_Owl 9]

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

[Солнцеворот 207]

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

Да ладно не переживайте? Если он в течение работы будет хранить ссылки на все создаваемые объекты, память очень быстро закончится и начнется аутофмемори. А если сформирует программу таким образом, чтобы она удаляла ссылки на более неиспользуемые объекты, памяти потребуется минимальное количество.

[streamdown 1 565]

массив children мы можем освободить

 

NULL reference и сборщик мусора

А вообще, с какой целью вы хотите вручную освобождать память от объектов в JVM? 

Дельный совет:

Не забывайте что вы на java

 

[Солнцеворот 207]

Топикстартер положил болт на тему. Я тут вспомнил, на форуме была размещена вакансия для Java-программиста для доработки какой-то PLM...

[Wise_Owl 9]

Как с этим бороться?

 

можно обойти дерево на всю глубину вложенности и без рекурсии, но это себе дороже. Код сложнее, чтоб помнить все уровни вложения. Время обработки больше. Больше вероятность наделать ошибок....

А в рекурсии все ваши лишние метки освободятся и удалятся как только она закончится.

 

 

Обход состава изделия на яве говорит о том, что это выполняется на клиентской части тимцентра. Да еще и наверняка нужно собрать информацию с каждой ветки(прочитать значения свойств). Поскольку это не на сервере, то уже затраты по времени возрастают. А вы еще и от рекурсии хотите отказаться. При огромных составах, думаю, логичнее это делать на серваке с целью экономии времени. А при среднем количестве строк(при котором время не критично) память не успеет закончится.

Изменено 14 октября 2014 пользователем Wise_Owl

[PostDeveloper 16]

примерно так(до Java 7):

SomeClass some = null;

try {

     some = new SomeClass();

     // Ваши действия с объектами

} finally {

  if (some!=null) {

      some.close();

  }

}

В Java 7 появилось  "syntactic sugar":
try (SomeClass some = new SomeClass(new FileReader(path)))

{
     return br.readLine();
}
 

[lexx174 373]

работайте напрямую с ораклом.быстродействие выше в разы. если речь идет о клиенте 8/8.3 то он сам по себе глючный в плане что порой жалуются на его тормоза или аварийное завершение. сименс толком ничего не улучшил в этом плане не смотря на ряд патчей

[Anto-Xa 1]

работайте напрямую с ораклом

 

Каким образом?

[Geksa 5]

Выполняется да, на клиенте.  По каждой bom_line получаем инфу.  на средние сборки памяти-то хватает, а вот когда получаем состав всего головного изделия, то получается, что памяти не хватает и Тимцентр отваливается.

[PostDeveloper 16]

Выполняется да, на клиенте.  По каждой bom_line получаем инфу.  на средние сборки памяти-то хватает, а вот когда получаем состав всего головного изделия, то получается, что памяти не хватает и Тимцентр отваливается.

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

[lexx174 373]

скорее всего имеется ввиду что интерфейс сам схлопывается(окно исчезает навсегда)

 

Выполняется да, на клиенте.  По каждой bom_line получаем инфу.  на средние сборки памяти-то хватает, а вот когда получаем состав всего головного изделия, то получается, что памяти не хватает и Тимцентр отваливается.

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

 

 

работайте напрямую с ораклом

 

Каким образом?

 

 

прямым. погуглите как работать на java с oracle. 

От вас прежде всего потребуется знание - где в каких таблицах teamcenter хранит те или иные данные и связи между ними.

Это  немного другой подход требующий работы в другой плоскости но для определенных задач(отчеты) он самое то.

 

на некоторых предприятиях ряд решений по построению отчетов в teamcenter базируется именно на прямом взаимодействии с oracle (связка "запросы к БД + редактор отчетов"). 

 

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

На классическом java-api процесс порой идет долго(работа на стороне клиента),если алгоритм реализовать на ITK - будет чуть быстрей но не всегда,SOA будет пошустрей, но прямые запросы в oracle мне кажется вне конкуренции

[PostDeveloper 16]

скорее всего имеется ввиду что интерфейс сам схлопывается(окно исчезает навсегда)

интересно, а в процессах остаётся запущенное приложение?

[Wise_Owl 9]

Выполняется да, на клиенте. По каждой bom_line получаем инфу. на средние сборки памяти-то хватает, а вот когда получаем состав всего головного изделия, то получается, что памяти не хватает и Тимцентр отваливается.

вы анализировали какой именно памяти не хватает?  может запускать Тс с дополнительными параметрами памяти к примеру -Xms256m -Xmx1024m -XX:PermSize=512m   (или как то так)