Outofmemory при чтении больших объемов данных с использованием Hibernate
-
19-09-2019 - |
Вопрос
Мне нужно экспортировать большое количество данных из базы данных. Вот классы, которые представляют мои данные:
public class Product{
...
@OneToMany
@JoinColumn(name = "product_id")
@Cascade({SAVE_UPDATE, DELETE_ORPHAN})
List<ProductHtmlSource> htmlSources = new ArrayList<ProductHtmlSource>();
... }
ProductHtmlSource
- Содержит большую строку, внутри которой мне действительно нужно экспортировать.
Поскольку размер экспортируемых данных больше, чем память JVM, я читаю свои данные кусочками. Как это:
final int batchSize = 1000;
for (int i = 0; i < 50; i++) {
ScrollableResults iterator = getProductIterator(batchSize * i, batchSize * (i + 1));
while (iterator.getScrollableResults().next()) {
Product product = (Product) iterator.getScrollableResults().get(0);
List<String> htmls = product.getHtmlSources();
<some processing>
}
}
Код getProductIterator
:
public ScrollableResults getProductIterator(int offset, int limit) {
Session session = getSession(true);
session.setCacheMode(CacheMode.IGNORE);
ScrollableResults iterator = session
.createCriteria(Product.class)
.add(Restrictions.eq("status", Product.Status.DONE))
.setFirstResult(offset)
.setMaxResults(limit)
.scroll(ScrollMode.FORWARD_ONLY);
session.flush();
session.clear();
return iterator;
}
Проблема в том, что, несмотря на то, что я очищал сеанс после чтения каждой части данных Product
Объекты накапливаются где -то, и я получаю исключение из -за исключения. Проблема не в обработке блока кода, даже без него я получаю ошибку памяти. Размер партии также не является проблемой, поскольку 1000 объектов легко сидят в памяти.
Профилировщик показал, что объекты накапливаются в org.hibernate.engine.StatefulPersistenceContext
учебный класс.
The Stacktrace:
Caused by: java.lang.OutOfMemoryError: Java heap space
at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:518)
at java.lang.StringBuffer.append(StringBuffer.java:307)
at org.hibernate.type.TextType.get(TextType.java:41)
at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:163)
at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:154)
at org.hibernate.type.AbstractType.hydrate(AbstractType.java:81)
at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2101)
at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1380)
at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1308)
at org.hibernate.loader.Loader.getRow(Loader.java:1206)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580)
at org.hibernate.loader.Loader.doQuery(Loader.java:701)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1994)
at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:36)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:565)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:63)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1716)
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109)
at org.hibernate.collection.PersistentBag.size(PersistentBag.java:225)
**at com.rivalwatch.plum.model.Product.getHtmlSource(Product.java:76)
at com.rivalwatch.plum.model.Product.getHtmlSourceText(Product.java:80)
at com.rivalwatch.plum.readers.AbstractDataReader.getData(AbstractDataReader.java:64)**
Решение
Похоже, что вы звоните GetProductiterator () с начальными и окончательными номерами строк, в то время как getProductiterator () ожидает начальной строки и подсчеты строк. По мере того, как ваш «верхний предел» становится выше, вы читаете данные в больших кусках. Я думаю, что вы хотите передать пакетирование в качестве второго аргумента GetProductiterator ().
Другие советы
Не прямой ответ, но для такого рода манипуляций с данными я бы использовал Интерфейс без сохранения состояния.
Кейтл прав - вы проходите постоянно растущий лимит. Но в любом случае нарушение этого не имеет смысла. Весь смысл прокрутки курсора заключается в том, что вы обрабатываете ряд за раз, поэтому нет необходимости разбивать его на куски. Размер выборки уменьшает поездки в базу данных за счет использования большего количества памяти. Общий шаблон должен быть:
Query q = session.createCriteria(... no offset or limit ...);
q.setCacheMode(CacheMode.IGNORE); // prevent query or second level caching
q.setFetchSize(1000); // experiment with this to optimize performance vs. memory
ScrollableResults iterator = query.scroll(ScrollMode.FORWARD_ONLY);
while (iterator.next()) {
Product p = (Product)iterator.get();
...
session.evict(p); // required to keep objects from accumulating in the session
}
Тем не менее, ошибка - это GethtmlSources, поэтому проблема может быть полностью не связана с проблемой сеанса/курсора/прокрутки. Если эти HTML -строки огромны, и они ссылаются все время, у вас может быть просто непрерывная память.
Кстати, я не вижу метода GetScrollableResults на ScollableResults.
Рискуя казаться глупым - вы думали о том, чтобы сделать это по -другому?
Лично я бы избежал партийной обработки, которая «далеко» из базы данных. Я не знаю, какую базу данных вы используете, но обычно существует механизм для эффективного вытягивания набора данных из базы данных и в файл, даже если он включает в себя умеренно простые манипуляции на выходе. Хранимые процедуры, конкретные экспортные утилиты. Изучите, что еще доступно у вашего поставщика базы данных.
Можете ли вы опубликовать исключение Stacktrace? Это может быть решено путем передачи подходящих вариантов JVM для GC.
Я думаю, что это связано - Java StringBuilder огромные накладные расходы.
Смотрит из Stacktrace, что создается очень большая строка и вызывает исключение.