XOM Parser Из памяти кучи

Question

Я разбираю файлы с помощью библиотеки XOM. Java-приложение работает хорошо, но я встречаю проблему с памятью, когда я разбираю большие файлы более 200 МБ.

сталкивается памятью размера кучи, когда я создаю файл, используя приведенный ниже фрагмент кода

 Builder profileFileBuilder = new Builder(profileFileXMLReader); 
     Document profileFileDocument = profileFileBuilder.build(profileFile); 

Каковы мои варианты для построения файлов с этим размером ?. Я попытался выделить больше памяти для виртуальной машины Java, но она не принимает более 1024 MBs

Спасибо заранее

Answer 1

Вы можете использовать XOM в качестве потокового анализатора, расширив NodeFactory, чтобы он не хранил XML в памяти, а обрабатывал его, а затем забывал об этом. Это хорошо работает для XML, который имеет множество небольших узлов, обернутых в элемент контейнера. Например, XML, как:

 
<records> 
    <record><a_little_xml/></record> 
    <record><a_little_xml/></record> 
    <record><a_little_xml/></record> 
    <record><a_little_xml/></record> 
    <record><a_little_xml/></record> 
</records> 

Существует пример в XOM документации о том, как продлить NodeFactory: http://www.xom.nu/tutorial.xhtml#Lister

Вы в основном анализировать содержание (на любом уровне в документе вы заинтересованы в) и затем не добавляйте его в дерево с памятью: http://www.xom.nu/tutorial.xhtml#d0e1424

Answer 2

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

Процессор Xalan XSLT, например, использует SAX-анализатор для создания собственной модели данных, а не DOM (XSLT, в общем, требует произвольного доступа к содержимому документа, поэтому требуется некоторая модель в памяти), и, по возможности, производит выход непосредственно в сериализатор SAX.

Принимая во внимание то, что вы может создать модель данных, которая явно вставляет и обрабатывает часть документа в документе, а не рассчитывает на swapper операционной системы. Однако я не уверен, что это будет чистая победа.

DOM - замечательная вещь, заметьте (он говорит, как один из ее авторов), но, как инструмент общего назначения, это не идеальный ответ для всех задач.

BTW, при отладке Xalan на некоторых более сложных проблемах, которые я довольно часто устанавливал -Xmx выше 1024 м. Будет ли Java позволять вам использовать более высокие значения, зависит от конфигурации JVM и вашей операционной системы, но я бы сказал, что стоит дважды проверить, можете ли вы немного подтолкнуть ее.