Необычный всплеск количества потоков каждую полночь в приложении Spring Boot ⇐ JAVA

[Anonymous]

Контекст приложения. В настоящее время мы развертываем приложение на основе Spring-boot:3.2.0, которое включает в себя API-интерфейсы на основе REST, предоставляемые клиентам с помощью Spring-boot-starter-web< /code>, интеграция с нашим хранилищем данных через org.springframework.boot:spring-boot-starter-data-elasticsearch, дополненная кешем в памяти на основе com.github.ben-manes.caffeine:caffeine< /code> и использует org.springframework.kafka:spring-kafka.
Проблема: каждую полночь ровно в 00:00 количество потоков наше приложение резко возрастает, и после этого очень немногие потоки завершаются, в результате чего наше приложение получает постепенно увеличивающиеся потоки каждый день, что иногда приводит к перезапуску модулей (подозреваю, что это из-за OOM по мере увеличения использования памяти).


Наблюдение< /strong>: в течение этого времени наблюдается небольшое отклонение в структуре пропускной способности для запросов на основе REST или конвейеров обработки сообщений.

Попытка: Итак, мы попытались проанализировать дамп потока нашего приложения и сравнили дамп за два разных дня. Одним из основных видимых аспектов было то, что в нашем приложении имеется значительное количество потоков, ожидающих timed_wait.


stacktrace для них выглядит так:
"http-nio-8080-exec-61" #37660 [37664] daemon prio=5 os_prio=0 cpu=38462.67ms elapsed=46889.40s tid=0x00007f2e0c0557b0 nid=37664 waiting on condition [0x00007f2ddf2fe000]
java.lang.Thread.State: TIMED_WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@21/Native Method)
- parking to wait for (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(java.base@21/LockSupport.java:269)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java.base@21/AbstractQueuedSynchronizer.java:1758)
at java.util.concurrent.LinkedBlockingQueue.poll(java.base@21/LinkedBlockingQueue.java:460)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:99)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:33)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1113)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1176)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.runWith(java.base@21/Thread.java:1596)
at java.lang.Thread.run(java.base@21/Thread.java:1583)


Требуется помощь: Но отсюда мы сейчас не понимаем, в каком направлении искать. С нетерпением ждем советов от сообщества:

• Может ли одна из упомянутых библиотек иметь конфигурацию по умолчанию для выполнения какой-либо внутренней задачи JVM ровно в 00:00? ?
• Основываясь на трассировке стека дампа, как нам определить, каким процессом был создан объект, которого ждут многие потоки? (дополнительная информация)

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

Обновление: свойства Web и tomcat переопределены для приложения в установка включает в себя:
spring.servlet.multipart.max-file-size=10MB
spring.servlet.multipart.max-request-size=10MB
server.servlet.context-path=/places/api

server.tomcat.accesslog.enabled=true
server.tomcat.accesslog.suffix=.log
server.tomcat.accesslog.prefix=access_log
server.tomcat.accesslog.file-date-format=.yyyy-MM-dd
server.tomcat.accesslog.pattern=%h %l %t "%r" %s %b "%{Referer}i" "%{User-Agent}i" %D
server.tomcat.accesslog.rotate=true
server.tomcat.basedir=/var/log
server.tomcat.accesslog.directory=places
server.tomcat.accesslog.max-days=7


Подробнее здесь: https://stackoverflow.com/questions/781 ... pplication