Java получает время от ОС через системный вызов. Это должно в свою очередь получить время от аппаратных часов.
Теперь аппаратные часы могут дрейфовать. Когда вы работаете с виртуальной машиной, аппаратные часы могут эмулироваться виртуальной платформой и могут дрейфовать больше, чем вы ожидаете. Это может зависеть от нагрузки на вашу виртуальную машину ... или от нагрузки на гипервизор с вашей виртуальной машины и других на вычислительное оборудование.
Но решение, скорее всего, заключается в том, чтобы использовать утилиты NTP для синхронизации системных часов виртуальной машины с надежной службой времени вне машины.
Я увеличил размер пула потоков, и он начал работать правильно, поэтому это должно быть узкое место в пуле потоков
Возможно, вы преждевременно спешите с выводами здесь. Кстати, я никогда не слышал, чтобы точность часов зависела от размера пула потоков Java.
Я имел в виду, что, вероятно, понадобилось некоторое время, чтобы пул потоков был готов предоставить какой-то поток для обработки моей задачи, в которой я вызывал новый Date()
.
Ах. Понимаю. Хорошо, если вы фиксируете время начала запроса в рабочем потоке, и в пуле недостаточно потоков, то то, что вы получаете с new Date()
, скорее всего, будет точной отметкой времени (относительно системных часов) ; время не синхронизировано.
Но вопрос в том, хорошо ли в этой ситуации увеличивать размер пула потоков. Время запуска отложенного запроса связано с тем, что слишком мало работников или слишком высокая частота запросов?
Конечным ограничивающим фактором пропускной способности будут такие факторы, как количество ядер, объем памяти, производительность базы данных, пропускная способность сети и т. Д. Увеличение пула потоков может позволить параллельно обрабатывать больше запросов. Однако, если у вас уже не хватает ресурсов, это не увеличит скорость обработки запросов. Действительно, чрезмерное количество рабочих потоков может привести к:
- увеличено использование памяти и загрузка GC,
- отдельные запросы занимают так много времени, что клиент их истекает.