JVM + Память + GC без боли: моя шпаргалка для собесов в Java. Часть 2

Если мне не изменяет память, то под капотом Kotlin все равно проставляет static поля, но в котле это слово не вынесено и не пишется(за исключением как раз @JvmStatic), чтобы переложить это на JVM, то есть меньше ручных ошибок и другой уровень абстракции)

Spring без боли: моя шпаргалка для собесов в Java. Часть 3

Доказывать что-то мне нет смысла)
Информацию беру из конспектов + пытаюсь добавить что-то интересное и из интернета, конечно, помогают LLM, грех не пользоваться. Насчет ошибки в примере - она была, вчера, когда правил код с телефона стер не нужное, бывает, все ошибаются, не вижу в этом ничего плохо. Я только начинаю писать статьи, поэтому спасибо вам за критику и комментарий)

JVM + Память + GC без боли: моя шпаргалка для собесов в Java. Часть 2

У меня ни разу не спрашивали, но кто знает, что в голове у интервьюера)

JVM + Память + GC без боли: моя шпаргалка для собесов в Java. Часть 2

Нужно людям, которые готовятся к собесам, а в работе эта инфа особо не нужна)

Spring без боли: моя шпаргалка для собесов в Java. Часть 3

Так я уже)

Spring без боли: моя шпаргалка для собесов в Java. Часть 3

Да, извиняюсь, пример взял с другого класса, не оттуда 😅

Поправил в статье, спасибо большое!)

JVM + Память + GC без боли: моя шпаргалка для собесов в Java. Часть 2

не понял вопрос)

Многопоточность без боли: моя шпаргалка для собесов в Java

Я согласен на 100 процентов, в этом плане собесы всегда так проводились, запоминаешь кучу инфы, перечитываешь конспекты, потому больше половины ты не используешь)

Как это грустно бы не было, прохождение собесов сейчас это навык, который нужно качать)

Многопоточность без боли: моя шпаргалка для собесов в Java

Здесь больше шпаргалка для собесов, которую можно взять и почитать перед собесом, нет прям глубины и подкоподщины. Статья делалась именно для цели подготовки)

Многопоточность без боли: моя шпаргалка для собесов в Java

Спасибо за комментарий, да, немного ошибся, спасибо за поправку, внес правку в статью)

Многопоточность без боли: моя шпаргалка для собесов в Java

Вы правы, что нельзя гарантировать через какое время поток увидит обновление.
Но JMM гарантирует, что когда он его увидит — оно будет правильным, и все предыдущие эффекты будут видны.

Это и есть happens-before между volatile write - volatile read)

Многопоточность без боли: моя шпаргалка для собесов в Java

Тут я имел ввиду именно по синтаксису, а так да, все правильно, статические по Class, а экземпляры по this)

Как дефолтная пагинация в Spring сломала проект и как это починить

Прошу прощения, я не так выразился, я имел ввиду поле в where которое отвечает за выборку keyset. Where id > 100, например, что дальше, конечно не нужно. Поправил в статье, спасибо)

Как дефолтная пагинация в Spring сломала проект и как это починить

Нужно индексировать поля самой частой сортировки и всё равно делать доп. сортировку по id.

Пример сортировка по created_at:

Ты хочешь показывать пользователей по дате создания:

SELECT id, name, created_at
FROM users
WHERE (created_at, id) > (:lastCreatedAt, :lastId)
ORDER BY created_at, id
LIMIT 100;

И под это создаёшь индекс:

CREATE INDEX idx_users_created_at_id ON users(created_at, id);

Если сортировать только по created_at, то:

• при одинаковом created_at порядок строк не детерминирован,

• PostgreSQL может перепрыгнуть или дублировать строки при переходе между страницами.

Добавление id в сортировку делает порядок уникальным и стабильным.

Конечно, не всегда удобно следить за частотой выборки и добавлять кучу индексов, но это стоит того)

Как дефолтная пагинация в Spring сломала проект и как это починить

Отличный вопрос, потому что многие отказываются от keyset не зная, что делать в таком случае)
Я бы сделал так -

1) Оставил UUID как первичный ключ (для API, бизнес-логики)
2) Добавил техническое поле (например, long seq_id) и использовать его для пагинации.

Это очень распространённый паттерн: публичный id — UUID, внутренний ordering id — последовательный bigint. И обязательно нужно заиндексировать seq_id

Пример SQL в таком случае:

SELECT id, name, seq_id
FROM users
WHERE seq_id > 100
ORDER BY seq_id
LIMIT 10;

Самая главная проблема такого подхода в том, что у long seq_id будет лимит значений, который может исчерпаться, ведь long не резиновый)

Подключаем LLMку в свой Java/Kotlin проект через Docker

Да, если указать stream true, то он будет работать не корректно, тут я даже спорить не буду, конечно, там есть еще параметры, просто в моей самой простой интеграции я их опустил, а так, да, есть еще доп параметры что в запросе, что в ответе, согласен

Подключаем LLMку в свой Java/Kotlin проект через Docker

Понятно, что все в ОЗУ и она будет не такой крутой, но на рабочих ноутах, которые выдают сейчас, это все, что есть, да и многие работают на них)

Я показывал как сделать это из Java, поэтому и все приложил, чтобы можно было по коду запустить и посмотреть, как пример)

Что такое JOOQ и как его едят на примере Kotlin + Gradle + JOOQ

Тоже хорошее решение, самое главное, чтобы после добавления миграций не забывали делать таску JOOQ, иначе плохо кончится)