Ошибка спящего режима памяти

Question

У меня есть Java-приложение, которое, помимо прочего, выходит на наш сервер Active Directory каждый час, собирает список всех учетных записей и выгружает их в базу данных; эта работа выполняется через поток, который порождает новый каждый час, а взаимодействие с базой данных осуществляется через Hibernate. Метод запуска потока (по сути, единственное, что делает этот поток) выглядит так:

public void run() {
    try {
        Thread.sleep(3600000); //we run once an hour, so we sleep for an hour
        Thread newHourlyRunThread = new Thread(new HourlyRunThread());
        newHourlyRunThread.start();
        LDAPNewUsersReport report = new LDAPNewUsersReport();
        Calendar calendar = Calendar.getInstance();
        calendar.set(0, 0, 0, 0, 0); //We tell the report to look for everything from 12AM Jan 1 0 AD, which should be sufficient to find all created AD objects.
        report.runReport(calendar.getTime(), new Date());
        HashSet<LDAPEntry> allEntries = report.getAllEntries();
        Iterator it = allEntries.iterator();
        while (it.hasNext()) {
            ContactParser.parseContact((LDAPEntry) it.next());
        }
}

Ниже приведены соответствующие методы ContactParser:

public static void parseContact(LDAPEntry entry) {
    Contact chosenContact = null;
    Session session = HibernateUtil.getSessionFactory().getCurrentSession();
    session.beginTransaction();

    List contacts = session.getNamedQuery("ContactByCanonicalName").setString(0, entry.getDN()).list();
    Iterator it = contacts.iterator();
    if (it.hasNext()) {
        chosenContact = (Contact) it.next();
        chosenContact = ContactParser.fillContactFields(chosenContact, entry);
    } else {
        chosenContact = ContactParser.fillContactFields(new Contact(), entry);
    }
    session.saveOrUpdate(chosenContact);
    session.getTransaction().commit();
}

private static Contact fillContactFields(Contact chosenContact, LDAPEntry entry) {
    chosenContact.setCanonicalName(entry.getDN());
    chosenContact.setFirstName(ContactParser.getEntryField(entry, "givenName"));
    chosenContact.setLastName(ContactParser.getEntryField(entry, "sn"));
    chosenContact.setUserName(ContactParser.getEntryField(entry, "sAMAccountname"));
    chosenContact.setEmployeeID(ContactParser.getEntryField(entry, "employeeID"));
    chosenContact.setMiddleName(ContactParser.getEntryField(entry, "initials"));
    chosenContact.setEmail(ContactParser.getEntryField(entry, "mail"));
    if(chosenContact.getFirstSeen() == null){
        chosenContact.setFirstSeen(new Date());
    }
    chosenContact.setLastSeen(new Date());
    return chosenContact;
}

private static String getEntryField(LDAPEntry entry, String fieldName){
    String returnString = "";
    if(entry.getAttribute(fieldName) != null){
        returnString = entry.getAttribute(fieldName).getStringValue();
    }
    return returnString;
}

Это все работает очень хорошо, если мы запускаем только один экземпляр (поэтому новые потоки не создаются по факту), но если мы запускаем этот поток более одного раза (IE, я ускоряю выполнение до ~ 30 секунд чтобы я мог видеть проблемы), Hibernate сообщает об отсутствии места в куче. Похоже, это не слишком интенсивный набор данных (всего около 6 тыс. Записей), но я вижу ту же ошибку, когда мы помещаем код в промежуточную ошибку, чтобы подготовиться к запуску в производство. Я неопытен, когда дело доходит до написания эффективных потоков, и очень неопытен, когда дело доходит до Hibernate, поэтому, если у кого-то есть идея, что может исчерпать наше пространство кучи (другой основной поток в этом приложении не работает одновременно и, глядя на код, занимает несколько сотен килобайт памяти), я был бы очень признателен за любые предложения.

Заранее спасибо.

Answer 1

Вы можете переписать это, используя ScheduledExecutorService, я подозреваю, что отчасти проблема в том, что вы создаете множество HourlyRunThread объектов, когда вам нужен только один.

Например, этот тест иллюстрирует, как запланировать выполнение потока каждую секунду в течение 10 секунд

@Test(expected = TimeoutException.class)
public void testScheduledExecutorService() throws InterruptedException, ExecutionException, TimeoutException {
    final AtomicInteger id = new AtomicInteger();
    final ScheduledExecutorService service = Executors.newScheduledThreadPool(1);
    service.scheduleAtFixedRate(new Runnable() {
        public void run() {
            System.out.println("Thread" + id.incrementAndGet());
        }
    }, 1, 1, TimeUnit.SECONDS).get(10, TimeUnit.SECONDS);
}

Это дает вывод, который вы ожидаете при запуске, поскольку этот тест создает почти 10 тыс. Потоков за 10 секунд выполнения

private static final class HourlyRunThread extends Thread {
    private static final AtomicInteger id = new AtomicInteger();
    private final int seconds;

    private HourlyRunThread(final int seconds) {
        super("Thread" + id.incrementAndGet());
        this.seconds = seconds;
    }

    public void run() {
        try {
            Thread.sleep(seconds);
            if (seconds < 10) {
                Thread newHourlyRunThread = new Thread(new HourlyRunThread(seconds));
                newHourlyRunThread.start();
            }
            // do stuff
            System.out.println(getName());
        } catch (InterruptedException e) {
        }
    }
}

@Test
public void testThreading() {
    final Thread t = new HourlyRunThread(1);
    t.start();
}

Answer 2

Похоже, что вы делаете пакетные вставки или обновления, и в этом случае вы должны периодически сбрасывать и очищать Hibernate Session, чтобы кэш уровня сеанса не заполнялся большим количеством места, чем вы выделили.

См. Главу в руководстве по Hibernate о Пакетная обработка , чтобы узнать, как этого добиться.

Кроме того, я настоятельно рекомендую найти другой способ запуска ваших задач на запланированном периоде, либо с помощью ScheduledExecutorService, как предложено Джоном Фридманом, либо с помощью библиотеки, такой как Quartz Scheduler . Задержка потока в течение 3600000 миллисекунд перед запуском фактического потока для выполнения работы кажется очень проблематичным (и недетерминированным) способом справиться с этим.

Answer 3

Memory Analyzer - бесплатный мощный анализатор кучи Java с открытым исходным кодом. Я уже использовал его несколько раз, чтобы определить источник утечек памяти. С помощью этого инструмента вы сможете быстро увидеть, является ли спящий режим наказанием; -)

Answer 4

Я случайно создавал новый sessionfactory для каждой транзакции.По какой-то причине GC не смог очистить эти старые sessionfactories.

Использование всегда одного и того же экземпляра SessionFactory решило мои проблемы.

Answer 5

Спасибо всем за предложения, но, как оказалось, полученная нами ошибка была вызвана ошибкой конфигурации между локальным тестированием и подготовкой. База данных была новой, а разрешения не были правильно настроены, чтобы разрешить размещение.область, чтобы говорить с созданной базой данных.При запуске с правильными разрешениями это работает как чудо.

Я обязательно рассмотрю настройку пакетных параметров для Hibernate и переход к планировщику потоков вместо моей текущей взломанной системы.