Подтвердить что ты не робот

Планировщик Java, который полностью не зависит от изменения системного времени

Использул Java Timer, затем переключился на ScheduledExecutorService, но моя проблема не исправлена. Поскольку Задачи, запланированные до изменения системного времени (через ntpd), не выполняются при указанной задержке. Нет журналов для того же, что ничего не происходит: (.

используя jre 1.6.0_26 64 бит в моей цели на 64-битном Linux.

Обновление: ScheduledExecutorService отлично работает в Windows. Проблема заключается только в 64-разрядной системе на базе Linux с 64-разрядной JVM. Он отлично работает на  64-разрядный Linux работает с 32-битным JVM... странным. Также не найдено ни одной ссылки на любые блоги.

IBM JAVA SDK имеет такую ​​же проблему (IBM-Java-СДК-7.0-0.0-x86_64-archive.bin).

Я подал дефект против JDK 7139684, он был принят, но был закрыт и отмеченный дубликат 6900441. Пожалуйста, проголосуйте за него, если вы чувствуете его стоит исправить... Я понятия не имею, почему это не было исправлено с более чем двух лет

Вот пример кода, который я использовал для проверки этой проблемы:

package test;

import java.io.IOException;
import java.util.Date;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;

/**
 * @author yogesh
 *
 */
public class TimerCheck  implements Runnable {

    ScheduledExecutorService worker;


    public TimerCheck(ScheduledExecutorService worker) {
        super();
        this.worker = worker;
        this.worker.schedule(this, 1, TimeUnit.SECONDS);
    }

    private static void update() {
        System.out.println("TimerCheck.update() "+new Date(System.currentTimeMillis()));
    }

    @Override
    public void run() {
            update();
            worker.schedule(this, 1, TimeUnit.SECONDS);
    }

    /**
     * @param args
     */
    public static void main(String[] args) {
        ScheduledExecutorService worker = Executors.newScheduledThreadPool(1);
        new TimerCheck(worker);
    }

}
4b9b3361

Ответ 1

Существует ошибка в JVM для общего планирования во время изменения времени Sytem назад, что также влияет на очень простые методы Object.wait и Thread.sleep. Слишком рискованно поддерживать Java-приложение, когда системное время переключается на определенные секунды. Вы никогда не знаете, к чему приведет ваше приложение Java.

Итак, мы решили:

  • Напишите часовую собаку script (не Java:)), чтобы проверить изменение времени.
  • Если время переключается на определенную величину, выключается и перезапускается Java-приложение.

Другой возможностью было перейти на 32-битную JVM, но мы используем JNI, а затем собственные библиотеки, используемые на целевой платформе, не совместимы с 32-битной. Также из нашего опыта 32-битная JVM ограничивает нашу цель до кучи 1,6 ГГц, чего нам не хватает.

Я знаю, что наше не самое элегантное решение, но до тех пор, пока JVM не будет исправлена ​​или не найдено какое-либо лучшее решение, похоже, что нет другого пути.

Отредактировано: Мы также рассматриваем первое предложение Криса в дополнение к вышеупомянутому решению:

  • Настройте NTP, чтобы никогда не было большого перерыва. Только убил время медленно. Используйте только длинные переходы вручную во время простоя.

Ответ 2

Я работал против той же проблемы и не нашел решения. Я посмотрел на Кварц и все встроенные методы JRE. Методы нанотимов могут использовать монотонные часы на процессор, но вы рискуете большими прыжками, если потоки переносятся на другой ЦП, я полагаю. Мои выводы были следующими:

  • Настройте NTP, чтобы никогда не было большого перерыва. Только медленно убил время. Используйте только длинные переходы вручную во время простоя.
  • Используйте несколько более коротких тайм-аутов и требуйте два таймаута, чтобы объявить удаленный компьютер мертвым. Это не поможет, если у вас есть только одна системная синхронизация, но может помочь с несколькими системами.
  • используйте удаленную машину для отправки периодических пробуждений. Если ваши собственные часы идут назад между пробуждениями, то вы знаете, что все ваши таймеры собираются с опозданием.

В принципе, это огромная боль, но нет серебряных пуль.