Утечка памяти WPF RichTextBox
Я имел успех с комбинацией Редактора WSDL Elipse WTP и SoapUI.
Eclipse Редактор WSDL WTP - http://wiki.eclipse.org/index.php/Introduction_to_the_WSDL_Editor
SoapUI - http://www.soapui.org/
4 ответа
Нашел это где-то в другом месте, и это кажется верным с точки зрения моего тестирования.
Когда создается FlowDocument, относительно дорогое форматирование объекты контекста также создаются для это в его StructuralCache. Когда ты создать несколько FlowDocs за один цикл StructuralCache создается для каждый FlowDoc. Давай ты позвонишь Gc. Собираем в конце петли, в надежде восстановить память. StructuralCache имеет финализатор освобождает этот контекст форматирования, но не сразу. Финализатор эффективно планирует операцию выпускать контексты в DispatcherPriority.Background.
Итак, RichTextBox (или FlowDocument) в случае, если не протекает, просто ожидая очистки фонового потока. Когда именно он запустится, кто знает. Я бы хотел, чтобы здесь был реализован метод удаления, который бы принудительно выполнял очистку.
Это не показатель того, что ваше приложение имеет утечку памяти, это показатель того, что ваше приложение использует много памяти . Утечка возникает, если элементы управления RichTextBox не выпускаются в какой-то момент после того, как они выпадают из области видимости (обнаружение утечек памяти на управляемых объектах, как известно, сложно и недоказуемо).
Распространенное заблуждение, что выпадение объекта за пределы области действия приведет к сборке мусора. Это просто делает его подходящим для сбора . Теоретически объект никогда не может быть собран до завершения работы приложения. Тот факт, что он увеличивается вместе с RichTextBox , а не с другими элементами управления, не является признаком утечки памяти в RichTextBox , это просто показатель того, что он использует больше памяти для каждого экземпляра, чем другие элементы управления. Хотя эта информация может быть полезной, она не помогает при определении наличия утечки памяти.
У нас была такая же проблема в winforms 2.0, и нам пришлось купить сторонний элемент управления форматированным текстом. Я полагаю, что Microsoft не удосужилась исправить это ...
Относительно вашего редактирования:
Вы добавили вызовы GC после , цикл завершился и все 3000 RichTextBox были созданы.
Хотя я согласен с тем, что кажется странным, что предыдущий не освобождается внутри цикла, когда он заменяется новым, это настолько плотный цикл, что GC, вероятно, не получает возможности «сделать это» раньше. цикл завершается.
Я не думаю, что это хорошая идея (но все должно быть в порядке в тестовом коде), но пробовали ли вы переместить вызовы GC внутри цикла?