Многопоточность без боли: моя шпаргалка для собесов в 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, иначе плохо кончится)