Ну и самые кишочки... )))

7) Internal - память под внутренние нужны JVM, не упомянутые выше. 

В частности здесь выделяются Direct ByteBuffers - https://docs.oracle.com/javase/8/docs/api/java/nio/ByteBuffer.html В случае объекта в heap, содержащего данные файла, ОС вначале копирует данные в свой низкоуровневый буфер, а потом JVM копирует данные к себе, то в случае Direct ByteBuffers этого можно избежать. Используются во многих высоконагруженных системах, в частности Kafka. 

Размер настраивается через XX:MaxDirectMemorySize=N. Нехватку памяти можно определить по "OutOfMemoryError: Direct buffer memory".

Т.к. ByteBuffer - объект, то сборщик мусора также умеет убирать и данные, выделенные в Direct ByteBuffers. Правда с некоторой задержкой, т.к. сами данные все же находятся не в куче, и механизм уборки получается чуть более сложный.

Сравнение скорости работы прямого и heap буфера с комментарием о том, что это всего лишь один из возможных случаев использования: https://elizarov.livejournal.com/20381.html


А увидеть все эти области можно запустив java процесс со специальным ключом XX:NativeMemoryTracking и используя утилиту jcmd из состава JDK.

Cм. детали тут https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html

Запускать в ПРОДе с этой опцией нужно с осторожностью, overhead может быть 5-10%


Может показаться, что главное - это heap, все остальное по сравнению с ним - мелочи. Это не всегда так, см. исследование https://shipilev.net/jvm/anatomy-quarks/


#java #interview_question

Всем привет!

Сегодня расскажу про такую штуку, как rate limiters.
Как следует из названия это компонент для ограничения числа запросов в интервал времени.
Может возникнуть вопрос - причем здесь Java? Да, обычно такие штуки разворачивают на инфраструктуре - например, в k8s или nginx.
Если так можно сделать - так и нужно делать)
Когда так сделать не получится:
1) алгоритм ограничения числа запросов нестандартный, поэтому нужна Java, чтобы его запрограммировать)
2) нужна возможность продвинутого мониторинга числа пропущенных и отбитых запросов
3) при изменении параметров rate limiting нужна умная ребалансировка. Т.е. нельзя просто сбросить счетчики в ноль, т.к. это приведет к падению сервиса, который защищает rate limiter.
4) ну и наконец нет подходящей инфраструктуры

Второй вопрос - в каких кейсах это может понадобиться:
1) не уронить стоящий за вами сервис
2) приоритизировать какие-то запросы вашего API по сравнению с другими чтобы не упасть самому
3) ограничить число запросов по тарифному плану клиента

Вот неплохая статья про существующие алгоритмы rate limiting https://habr.com/ru/post/448438
Неплохая библиотека для Java - Bucket4J https://github.com/bucket4j/bucket4j
Развивается порядка 8 лет, к слову разработчики из России.
Вот хорошее видео от разработчиков с примерам настройки - https://www.youtube.com/watch?v=OSNFNxgZZ3A
В простых случаях можно использовать Resilience4j, удобно со Spring Boot посредством аннотаций https://www.baeldung.com/spring-boot-resilience4j Resilience4j библиотека более широкого профиля, отвечает за отказоустойчивость, см. детали в статье

#java #libraries #highload #interview_question #rate_limiters