Мне нужен синтаксический анализатор xml для анализа файла размером примерно 1,8 ГБ.
Поэтому анализатор не должен загружать весь файл в память.
Любые предложения?
Помимо рекомендуемого анализа SAX, вы можете использовать STAX API (вид эволюции SAX), включенный в JDK (пакет javax.xml.stream).
Используйте синтаксический анализатор на основе SAX, который представляет вам содержимое документа в потоке событий.
API StAX проще справляться с SAX. Вот краткое руководство
Поток файла в синтаксический анализатор SAX и чтение его в память в кусках.
SAX дает вам большой контроль и управление событиями имеет смысл. Апи немного сложно понять, вам нужно обратить внимание на некоторые вещи, например, когда вызывается метод characters(), но основная идея заключается в том, что вы пишете обработчик содержимого, который вызывается, когда начинается и заканчивается каждый читается элемент xml. Таким образом, вы можете отслеживать текущий xpath в документе, определять, какие пути имеют данные, которые вас интересуют, и определить, какой путь обозначает конец фрагмента, который вы хотите сохранить или передать или каким-либо другим способом.
Попробуйте VTD-XML. Я считаю, что это более эффективный и, что более важно, более простой в использовании, чем SAX.
Как говорили другие, используйте синтаксический анализатор SAX, так как это потоковый анализатор. Используя различные события, вы извлекаете свою информацию по мере необходимости, а затем на лету храните ее где-то еще (база данных, другой файл, что у вас есть).
Вы даже можете сохранить его в памяти, если вам действительно нужно небольшое подмножество, или если вы просто суммируете файл. Зависит от варианта использования, конечно.
Если вы буферизируетесь в БД, убедитесь, что проявляете осторожность, чтобы сделать ваш процесс перезагруженным или каким-либо другим. Многое может случиться в 1,8 ГБ, что может потерпеть неудачу в середине.
Используйте почти любой SAX Parser для потока файл немного за раз.
У меня была аналогичная проблема - мне пришлось прочитать целый XML файл и создать структуру данных в памяти. В этой структуре данных (все должно было быть загружено) мне пришлось выполнять различные операции. Многие элементы XML содержали текст (который я должен был выводить в свой выходной файл, но не был важен для алгоритма).
В общем, как было предложено здесь, я использовал SAX для анализа файла и создания моей структуры данных. Мой файл был 4 ГБ, и у меня была 8-гигабайтная машина, поэтому я подумал, что, возможно, 3 ГБ файла - это просто текст, а java.lang.String, вероятно, потребуется 6 ГБ для этого текста, используя его UTF-16.
Если JVM занимает больше места, чем компьютер имеет физическую RAM, тогда машина будет меняться. Выполнение сбора мусора с меткой + sweep приведет к тому, что страницы получат доступ в случайном порядке, а также объекты, перемещаемые из одного пула объектов в другой, что в основном убивает машину.
Итак, я решил написать все свои строки на диск в файле (FS, очевидно, может обрабатывать последовательную запись 3GB в порядке, а при чтении в ОС будет использовать доступную память для кеша файловой системы; все равно могут быть чтения с произвольным доступом, но меньше, чем GC в java). Я создал небольшой вспомогательный класс, который вы более чем можете скачать, если вам это поможет: StringsFile javadoc | Скачать ZIP.
StringsFile file = new StringsFile();
StringInFile str = file.newString("abc"); // writes string to file
System.out.println("str is: " + str.toString()); // fetches string from file
+1 для StaX. Это проще в использовании, чем SaX, потому что вам не нужно писать обратные вызовы (вы, по сути, просто перебираете все элементы времени, пока не закончите), и у него (AFAIK) нет ограничений по размеру файлов, которые он может обрабатывать.