Java Books
Java Библиотека По всем вопросам- @notxxx1 @ai_machinelearning_big_data - machine learning @pythonl - Python @itchannels_telegram - 🔥 best it channels @ArtificialIntelligencedl - AI @pythonlbooks-📚 @programming_books_it -it 📚 № 5032728887
Show more📈 Analytical overview of Telegram channel Java Books
Channel Java Books (@java_library) is an active participant. Currently, the community unites 14 227 subscribers, ranking 8 720 in the Technologies & Applications category and 45 528 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 14 227 subscribers.
According to the latest data from 15 September, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -25 over the last 30 days and by -5 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 10.35%. Within the first 24 hours after publication, content typically collects 3.74% reactions from the total number of subscribers.
- Post reach: On average, each post receives 1 472 views. Within the first day, a publication typically gains 532 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 4.
- Thematic interests: Content is focused on key topics such as docker, собеседование, sql, boot, string.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Java Библиотека
По всем вопросам- @notxxx1
@ai_machinelearning_big_data - machine learning
@pythonl - Python
@itchannels_telegram - 🔥 best it channels
@ArtificialIntelligencedl - AI
@pythonlbooks-📚
@programming_books_it -it 📚
№ 503272888...”
Thanks to the high frequency of updates (latest data received on 16 September, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
HashSet зависит от количества элементов и размера внутренней таблицы.
var ids = new HashSet<Integer>(1_000_000);
for (int i = 0; i < 10; i++) {
ids.add(i);
}
for (int id : ids) {
process(id);
}
После добавления элементов внутри выделена огромная таблица. Итератор проходит по её ячейкам, включая пустые, хотя size() возвращает всего 10.
Сложность обхода - O(size + capacity). Поэтому большая ёмкость «про запас» может замедлить регулярный перебор.
Если коллекция уже сильно разрослась, а затем почти опустела, можно пересобрать её:
ids = new HashSet<>(ids);
Новый набор подберёт ёмкость под оставшиеся элементы. Пересборка требует времени и дополнительной памяти, поэтому имеет смысл перед многократными обходами, а не внутри каждого цикла.
Документация - https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/HashSet.html@Mcp.Tool. Клиенту не нужно знать, какая модель работает внутри.
Доступны два режима:
* локальный MiniLM через DJL - 384-мерные эмбеддинги, без API и сети;
* OpenAI text-embedding-3-small - 1536-мерные эмбеддинги.
Финальную оценку в обоих случаях вычисляет локальная нейросеть DeepNetts.
Важный нюанс: для каждого типа эмбеддингов нужна отдельно обученная модель оценки. Нельзя взять модель, обученную на векторах MiniLM, и передать ей векторы OpenAI, даже если привести их к одинаковому размеру.
MCP-интерфейс при этом остаётся неизменным:
жалоба → эмбеддинг → DeepNetts → срочность 0–10
Локальный режим подходит для разработки и интеграционных тестов, внешний - для проверки качества на более мощной модели.
https://inside.java/2026/07/25/design-java-mcp-tool/subList() может неожиданно удерживать огромный список в памяти
Кажется, что:
List<Item> small = hugeList.subList(0, 10);
hugeList = null;
оставит только 10 элементов.
Но subList() обычно создаёт представление исходного списка, а не независимую копию. Пока жив small, исходный ArrayList и его внутренний массив тоже могут оставаться в памяти.
Если нужна отдельная маленькая коллекция:
`
List<Item> small = new ArrayList<>(hugeList.subList(0, 10));
Особенно неприятный баг в кэшах и долгоживущих объектах: сохраняешь 10 элементов — а в памяти остаются сотни тысяч.stream(), добавлю parallelStream() — станет быстрее».
Но не всегда.
parallelStream() использует общий ForkJoinPool Java:
users.parallelStream()
.map(this::callExternalApi)
.toList();
Если внутри идут HTTP-запросы, SQL или ожидание внешнего сервиса, можно получить обратный эффект:
забить общий пул потоков
увеличить задержки
замедлить другие части приложения
parallelStream() хорошо подходит для:
✅ сложных CPU-вычислений
✅ обработки больших коллекций
✅ математических операций
Но плохо подходит для:
❌ HTTP
❌ базы данных
❌ файлового I/O
❌ ожидания внешних сервисов
Для таких задач лучше использовать отдельный пул:
ExecutorService executor =
Executors.newFixedThreadPool(20);
и контролировать количество параллельных операций.
Главное правило:
parallelStream() — для вычислений.
ExecutorService — для бизнес-логики и внешних вызовов.
Код может идеально работать на тестах, но в production внезапно получить проблемы из-за одного parallelStream().
private static final Map<Class<?>, Metadata> CACHE =
new ConcurrentHashMap<>();
На первый взгляд всё нормально.
Но в приложениях с динамической загрузкой классов — plugins, application servers, hot reload — такой кеш может удерживать Class, а вместе с ним и его ClassLoader.
И получить неприятную утечку памяти.
В Java для этого есть малоизвестный ClassValue<T>:
private static final ClassValue<Metadata> CACHE =
new ClassValue<>() {
@Override
protected Metadata computeValue(Class<?> type) {
return buildMetadata(type);
}
};
Использование:
Metadata metadata = CACHE.get(MyClass.class);
Что даёт ClassValue:
- ленивое вычисление значения для каждого класса;
- thread-safe доступ;
- не нужен собственный ConcurrentHashMap;
- кеш лучше согласован с жизненным циклом загруженных классов.
Особенно полезно для reflection, serializers, ORM, DI-контейнеров и framework-кода, где постоянно кешируются данные по Class<?>.
🔥 Если видишь в библиотеке:
static ConcurrentHashMap<Class<?>, ...>
стоит хотя бы задать вопрос:
а почему здесь не `ClassValue`?
#Java #JVM #Backend #Programming
CompletableFuture<User> future =
CompletableFuture.supplyAsync(() -> userClient.loadUser(id));
Но без явного Executor задача обычно попадёт в общий ForkJoinPool.commonPool().
Если loadUser() ждёт HTTP, базу данных или файловую систему, поток блокируется. Несколько медленных вызовов могут занять весь общий пул и затормозить совершенно несвязанные операции приложения.
Лучше выделить отдельный пул для блокирующего I/O:
private static final ExecutorService IO_POOL =
Executors.newFixedThreadPool(32);
CompletableFuture<User> future =
CompletableFuture.supplyAsync(
() -> userClient.loadUser(id),
IO_POOL
);
И не забыть корректно его закрыть:
IO_POOL.shutdown();
Для цепочки тоже важно явно выбирать executor:
future.thenApplyAsync(
user -> enrichUser(user),
IO_POOL
);
Почему это полезно:
- медленный внешний сервис не блокирует общий пул;
- нагрузку можно ограничить размером executor;
- проще наблюдать очередь и время выполнения;
- разные типы задач не мешают друг другу.
CompletableFuture не делает блокирующий код неблокирующим. Он лишь переносит ожидание в другой поток.
Асинхронность без контроля executor - это просто блокировка в менее заметном месте.