Java из Исключения памяти
Как другие отметили, худший случай Quicksort является O (n^2), в то время как сортировка с объединением и пирамидальная сортировка остаются в O (nlogn). В среднем случай, однако, все три являются O (nlogn); таким образом, они для подавляющего большинства сопоставимых случаев.
то, Что делает Quicksort лучше в среднем, - то, что внутренний цикл подразумевает сравнение нескольких значений с единственным, в то время как на другой два оба условия отличаются для каждого сравнения. Другими словами, Quicksort делает вдвое меньше чтений, чем другие два алгоритма. На современных центральных процессорах производительность в большой степени во власти времен доступа, таким образом, в конце Quicksort заканчивает тем, что был большим предпочтительным вариантом.
6 ответов
Everytime you use a DOM to parse a XML file, you'll load entire file into memory and DOM infrastructure will use about same size to handle it, so it'll consume about twice memory than your file size.
You'll need to use SAX, an event based parser. While this can be hard to understand it first time, it's a very memory effective, as it just keeps in memory current parsing node.
Seems Java have some SAX implementations, like StAX, I hope it helps.
Вы пытались установить максимальный размер кучи больше, чтобы увидеть, сохраняется ли проблема? Может и вовсе не быть утечки. Возможно, размер кучи по умолчанию (я думаю, 64 мб в Windows) недостаточен для этого конкретного процесса.
Я считаю, что почти всегда мне нужно предоставить любому приложению, в котором я использую Tomcat, больше места для кучи и перманентного генератора, чем по умолчанию, или я столкнусь с проблемами нехватки памяти. Если вам нужна помощь в настройке параметров памяти, прочтите этот вопрос .
Are you sure there are no recursive array copy somewhere, left there by mistake? Perhaps in different threads?
Я поддержу это замечание о файле и DOM, занимающих много памяти. Я также удивляюсь, когда вижу это:
ERROR [JobRunShell]: Job updateVendorData.quoteUpdate threw an unhandled Exception:
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOfRange(Arrays.java:3210)
Что делает это копирование? Интересно, не происходит ли что-то еще плохое в вашем коде.
Если вы зашли так далеко, это означает, что вы успешно прочитали файл и DOM и начали запись в базу данных. Файловая память уже должна быть освобождена.
Я бы посоветовал посмотреть на память, используя VisualGC , чтобы вы могли видеть, что происходит.
Анализ XML - довольно дорогостоящая задача. Среднему парсеру DOM уже потребуется по крайней мере пять раз больше пространства памяти, чем размер XML-документа. Вы также должны учитывать этот факт. Чтобы гарантировать отсутствие утечки памяти где-либо еще, которая вызвала нехватку памяти для анализатора XML, вам действительно нужно запустить профилировщик. Дайте ему больше памяти, удвойте доступную память и профилируйте ее. Когда вы установили причину и устранили утечку, вы можете просто вернуться к памяти «по умолчанию» и провести повторную проверку. Или, если на самом деле нет никаких средств утечки, просто дайте всем немного больше памяти, чем по умолчанию, чтобы все подходило.
Вы можете запустить свое приложение с помощью: -XX: + HeapDumpOnOutOfMemoryError. Это приведет к тому, что JVM будет создавать дамп кучи при нехватке памяти. Вы можете использовать что-то вроде: MAT или JHAT, чтобы увидеть, за какие объекты держатся. Я предлагаю использовать инструмент анализатора памяти eclipse (MAT) для созданного дампа кучи, так как его довольно просто использовать: http://www.eclipse.org/mat/
Конечно, вам понадобится идея относительно того, какие объекты могут висеть вокруг, чтобы это было полезно. Объекты DOM? Ресурсы из предыдущих загрузок XML-документов? Подключения к базе данных? MAT позволит вам отследить ссылки на корневой объект от некоторого объекта, который, как вы подозреваете, должен был быть собран сборщиком мусора.