2015-08-06 2 views
0

У меня возникли некоторые проблемы с потреблением памяти при использовании JFXtras Agenda. Сначала я подумал, что это на мне, потому что я реализовал свой собственный Skin, который производит переменное число «столбцов». Но это та же проблема с приложением FXSampler. Через 5-10 минут, играя на арнометре, добавляя встречи, удаляя встречи, переключая скины и т. Д. VisualVM сообщает мне размер кучи около 1,2 ГБ (три четверти его использованного)JFXtras Расход памяти памяти

Я попытался найти решение, но нет успех до сих пор. Я могу сказать: Удаление и добавление назначений очень тяжелое - когда я не опустошаю свой наблюдаемый список при переключении скинов, у меня почти нет проблемы с памятью. «Как-то» встречи и некоторые слушатели (например, назначенийListChangeListener) по-прежнему остаются активными после переключения скинов, хотя их нужно было удалить.

Возможно, идеи?

спасибо !!

Обновление: Дамп кучи с использованием VisualVM теперь позволил мне взглянуть на экземпляры класса. К сожалению, я до сих пор не могу добавлять изображения, но некоторые примеры:

com.sun.javafx.geom.RectBounds: 697990 экземпляров

AppointmentRegularBodyPane: 9236 экземпляров

AppoitmentMenu: 9236 экземпляров

... так что действительно существует проблема с уничтожением старых объектов

+0

У меня только что (вчера) исправлена ​​утечка памяти; сколько скинов находится в скин-переключателе? Если есть 2, у вас нет последнего моментального снимка. Вполне возможно, что их будет больше. Переключение между скинами относительно новое. – tbeernot

+0

ОК, так что я посмотрю на новый снимок. Где я могу найти основные изменения? Потому что мне, вероятно, придется применить их к моему коду «вручную». – clic

+0

Я применил слабых слушателей к своему коду. Возможно, некоторые улучшения, но все же проблемы связаны с проблемой: я могу несколько раз переключать свои скины, производительность и потребление памяти в порядке. Но как только я добавляю или удаляю встречу, размер кучи массивно растет. И я заметил, что для каждого изменения кожи, которое я сделал, срабатывает одно назначениеListChangeListener из AgendaSkinTimeScale24HourAbstract. (поэтому при переключении 10 раз, я получаю 10 раз одно и то же событие прослушивателя) – clic

ответ

0

Исправлено несколько проблем с памятью слушателя в 8.0-R4

+0

ОК спасибо! Помимо слабых слушателей, я достиг больших улучшений производительности/памяти, изменив концепцию освежения в повестке дня. Поэтому вместо того, чтобы всегда воссоздавать назначениеПанелей и ретранслировать все, я теперь использую объекты как можно дальше. В основном я достиг этого, передав текущее редактируемое/созданное назначение в методы setupAppointment и отреагировав соответствующим образом. Это помогло мне уменьшить текущее потребление памяти, например. действие перетаскивания от 30-40 МБ до 3-4 МБ. – clic

+0

Да, я тоже хотел посмотреть на это. У меня была версия, которая использовала кеш панелей, но я этого не делал. Вам интересно участвовать? – tbeernot

Смежные вопросы