10986
📚 Лайфхаки, приёмы и лучшие практики для Java-разработчиков. Всё, что ускорит код и прокачает навыки. Java, Spring, Maven, Hibernate. По всем вопросам @evgenycarter РКН clck.ru/3KoGeP
🏗 SOLID - Пять заповедей программиста
Почему один проект живет 10 лет и его легко дорабатывать, а другой через полгода превращается в "Legacy", к которому страшно подходить?
Разница в соблюдении принципов SOLID.
Это аббревиатура из 5 правил, сформулированных Робертом Мартином (Дядя Боб). Если вы нарушаете их - ваш код "гниет".
Давайте разберем каждую букву.
1️⃣ S - Single Responsibility Principle (Единственная ответственность)
"У класса должна быть только одна причина для изменения."
OrderService делает всё:OrderCalculator (считает).OrderRepository (сохраняет).EmailNotificationService (шлет письма).PdfGenerator (печатает).OrderService теперь просто дирижер, который вызывает эти компоненты."Программные сущности должны быть открыты для расширения, но закрыты для модификации."
if (deliveryType == "DHL") { ... }
else if (deliveryType == "Post") { ... }
// Пришла задача добавить FedEx? Придется лезть сюда и добавлять else if!
interface DeliveryStrategy { void deliver(); }
class DhlDelivery implements DeliveryStrategy { ... }
class PostDelivery implements DeliveryStrategy { ... }
// Нужен FedEx? Просто создаем НОВЫЙ класс, не трогая старые!
class FedExDelivery implements DeliveryStrategy { ... }
"Наследники должны без проблем заменять родителей."
Bird с методом fly(), а вы создали наследника Penguin (Пингвин), который при вызове fly() бросает ошибку (потому что пингвины не летают) - вы нарушили LSP."Много маленьких интерфейсов лучше, чем один огромный."
Worker имеет методы work() и eat().Robot. Роботы работают, но не едят.eat() и оставить его пустым или кинуть ошибку. Это мусор.Workable и Eatable.Workable."Зависьте от абстракций, а не от конкретики."
Service не должен зависеть от PostgresRepository. Он должен зависеть от интерфейса Repository.
👮♂️ Spring Security: Фейсконтроль для вашего API
Spring Security - это не просто библиотека, это мощный фреймворк, который встает стеной между интернетом и вашим контроллером.
Его работа строится на концепции Filter Chain (Цепочка фильтров). Каждый запрос проходит через серию проверок: "Есть ли токен?", "Валиден ли он?", "Есть ли права?".
🔑 Authentication vs Authorization
Два слова, которые путают все джуниоры.
1. Authentication (Аутентификация): "Кто ты?"
🔴Ввод логина/пароля.
🔴Проверка отпечатка пальца.
🔴Ответ: 401 Unauthorized (если не знаем, кто это).
2. Authorization (Авторизация): "А что тебе можно?"
🔴Ты Вася (мы тебя узнали), но ты хочешь удалить базу данных. Тебе нельзя.
🔴Ответ: 403 Forbidden (знаем кто ты, но не пустим).
🎫 JWT (JSON Web Token) - Паспорт туриста
В микросервисах мы не храним состояние пользователя на сервере (Stateless). Вместо этого, при логине мы выдаем пользователю Токен.
JWT - это строка из трех частей, разделенных точками: Header.Payload.Signature.
🔴Payload: Полезные данные (User ID, Role, Email).
🔴Signature: Цифровая подпись сервера. Гарантирует, что хитрый хакер не поменял в токене роль USER на ADMIN.
Как это работает:
1. Клиент шлет Логин/Пароль -> Сервер проверяет и отдает JWT.
2. Клиент сохраняет JWT (обычно в LocalStorage браузера).
3. При каждом запросе клиент прикрепляет JWT в заголовок:Authorization: Bearer <token>
4. Сервер видит токен, проверяет подпись и пускает (не ходя в базу данных!).
🛡 Настройка (Spring Boot 3.x)
Раньше мы наследовались от WebSecurityConfigurerAdapter. Забудьте, этот класс Deprecated.
Сейчас мы просто объявляем бин SecurityFilterChain.
@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.csrf(AbstractHttpConfigurer::disable) // Для REST API отключаем
.sessionManagement(session -> session
.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) // Никаких сессий!
.authorizeHttpRequests(auth -> auth
.requestMatchers("/auth/**").permitAll() // Логин доступен всем
.requestMatchers("/admin/**").hasRole("ADMIN") // Админка только админам
.anyRequest().authenticated() // Всё остальное - только с токеном
)
// Добавляем наш кастомный фильтр для проверки JWT
.addFilterBefore(new JwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class);
return http.build();
}
}
application.yaml, но под капотом там огромная машина стандартов.
🎥 Открытый урок «Eclipse Memory Analyzer (MAT): помощь в работе с heap».
🗓 04 февраля в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «Java Developer. Advanced».
Без MAT сложно найти причины OutOfMemoryError и утечек. Разберём базу и полезные приёмы анализа heap dump.
🧩 Микросервисы: Укрощение хаоса (Spring Cloud)
Когда у вас один сервис, всё просто. Но когда их становится 10, 20 или 50, возникают вопросы:
1. Как сервису А узнать IP-адрес сервиса Б? (А если он меняется динамически?)
2. Как не писать тонны кода для HTTP-запросов?
3. Как клиенту (фронтенду) обращаться ко всей этой куче сервисов?
Для этого есть три главных инструмента.
1️⃣ Eureka: Телефонная книга (Service Discovery)
В облаке сервисы постоянно перезапускаются, меняют IP-адреса и порты. Хардкодить http://localhost:8081 в коде - самоубийство.
Eureka Server - это реестр.
🔴Когда сервис (например, OrderService) запускается, он звонит в Eureka: "Привет, я OrderService, мой IP такой-то".
🔴Когда UserService хочет найти заказы, он спрашивает Eureka: "Где сейчас живет OrderService?".
В коде:
Вам нужно просто добавить аннотацию @EnableDiscoveryClient, и магия произойдет сама. Сервисы будут находить друг друга по имени, а не по IP.
2️⃣ OpenFeign: Магия общения
Окей, адрес мы нашли. Теперь нужно отправить запрос.
Раньше мы использовали RestTemplate - это было громоздко и некрасиво.
Feign позволяет вызывать удаленный REST-сервис так, будто это обычный метод интерфейса в вашем коде.
Было (RestTemplate):
String url = "http://order-service/orders/" + userId;
List<Order> orders = restTemplate.getForObject(url, List.class); // Фу, нетипизированно
FeignClient):
@FeignClient(name = "order-service") // Имя сервиса в Eureka
public interface OrderClient {
@GetMapping("/orders/{userId}")
List<Order> getUserOrders(@PathVariable Long userId);
}
// Использование в сервисе:
// List<Order> orders = orderClient.getUserOrders(123L);
api.com:8081, api.com:8082...). Это небезопасно и сложно (CORS error, привет 👋)./users/** -> лети в UserService, /orders/** -> лети в OrderService.application.yaml):
spring:
cloud:
gateway:
routes:
- id: user-service
uri: lb://USER-SERVICE # lb = Load Balancer (через Eureka)
predicates:
- Path=/users/**
🧪 Тестирование в Spring Boot: Спите спокойно
Глобально тесты делятся на два лагеря:
1. Unit-тесты (Модульные): Быстрые, изолированные. Проверяем только логику одного класса (обычно Service). Никаких баз данных и поднятия Spring Context.
2. Integration-тесты (Интеграционные): Проверяем, как компоненты работают вместе (Controller + Service + DB). Здесь поднимается Spring Context.
⚡ 1. Unit-тесты: Изоляция и Скорость
Когда вы тестируете UserService, вам не нужно, чтобы он реально лез в базу данных. Вам нужно проверить: "Если репозиторий вернет null, выбросит ли сервис ошибку?"
Для этого мы используем Mockito - библиотеку, которая создает "фейковые" объекты (моки).
Ключевые аннотации:
🔴@ExtendWith(MockitoExtension.class) - включаем Mockito.
🔴@Mock - "Создай фейковый объект" (например, UserRepository).
🔴@InjectMocks - "Создай тестируемый объект (UserService) и вставь в него моки".
💻 Пример Unit-теста:
@ExtendWith(MockitoExtension.class) // 1. Включаем Mockito
class UserServiceTest {
@Mock
private UserRepository userRepository; // Фейк
@InjectMocks
private UserService userService; // Реальный сервис с фейком внутри
@Test
void shouldReturnUser_WhenExists() {
// GIVEN (Дано) - Настраиваем поведение мока
User mockUser = new User("Alex");
// "Если кто-то вызовет findById(1), верни mockUser"
Mockito.when(userRepository.findById(1L)).thenReturn(Optional.of(mockUser));
// WHEN (Когда) - Вызываем метод сервиса
User result = userService.findById(1L);
// THEN (Тогда) - Проверяем результат
Assertions.assertEquals("Alex", result.getName());
// Проверяем, что метод репозитория действительно вызывался 1 раз
Mockito.verify(userRepository, times(1)).findById(1L);
}
}
@SpringBootTest - Поднимает весь контекст приложения (тяжело и медленно, но честно).@WebMvcTest - Поднимает только веб-слой (Контроллеры). Сервисы и БД не грузятся.@MockBean - Главная магия Spring Test. Это как @Mock, только этот мок кладется прямо в Spring Context, заменяя собой настоящий бин.@WebMvcTest):
@WebMvcTest(UserController.class) // Грузим только контроллер
class UserControllerTest {
@Autowired
private MockMvc mockMvc; // Инструмент для имитации HTTP-запросов
@MockBean // Заменяем настоящий сервис заглушкой в контексте Spring
private UserService userService;
@Test
void shouldReturnStatus200() throws Exception {
Mockito.when(userService.findById(1L)).thenReturn(new User("Alex"));
mockMvc.perform(get("/users/1")) // Делаем GET запрос
.andExpect(status().isOk()) // Ждем 200 OK
.andExpect(jsonPath("$.name").value("Alex")); // Проверяем JSON
}
}
@Mock vs @MockBean - Не путать!@Mock (из org.mockito): Используется в Unit-тестах. Быстро. Spring про него ничего не знает.@MockBean (из spring-boot-test): Используется в Integration-тестах. Spring находит этот бин в контексте и подменяет его на мок. Медленнее.Mockito.when(...).MockMvc.
🎛 Конфигурация Spring Boot: YAML, Профили и Секреты
Хардкодить настройки (порты, пароли, URL-ы) в Java-коде - это моветон. Если вам нужно поменять порт сервера, вы не должны перекомпилировать приложение.
Spring Boot следует принципу: "Код отдельно, настройки отдельно".
1️⃣ Properties vs YAML
По умолчанию Spring создает application.properties. Это старый формат (ключ=значение).
Весь мир переходит на YAML (.yaml или .yml). Он читабельнее и поддерживает иерархию.
Было (.properties):
spring.datasource.url=jdbc:postgresql://localhost/db
spring.datasource.username=admin
server.port=8080
.yaml):
server:
port: 8080
spring:
datasource:
url: jdbc:postgresql://localhost/db
username: admin
@Value)
@Value("${server.port}")
private int port;
@ConfigurationProperties)
@ConfigurationProperties(prefix = "mail")
public record MailConfig(String host, int port, String username) {}
MailConfig в свои сервисы, как обычный бин.application.yaml:application-dev.yaml (для разработки)application-prod.yaml (для боевого сервера)
spring:
profiles:
active: dev # По умолчанию грузим dev-настройки
java -jar app.jar -Dspring.profiles.active=prodapplication-prod.yaml с паролем от боевой БД в репозиторий. ☠️spring.datasource.password=secretSPRING_DATASOURCE_PASSWORD=SuperSecurePass123@ConfigurationProperties.dev, test, prod).
💾 Spring Data JPA: SQL больше не нужен?
Spring Data JPA это абстракция над Hibernate (который, в свою очередь, является реализацией JPA).
Его главная киллер-фича: Генерация запросов из названий методов.
🏗 1. Сущность (@Entity)
Сначала мы объясняем Java, как выглядит наша таблица. Обычный класс превращается в таблицу с помощью пары аннотаций.
@Entity // Это таблица в БД
@Table(name = "users")
public class User {
@Id // Это Primary Key
@GeneratedValue(strategy = GenerationType.IDENTITY) // Авто-инкремент
private Long id;
private String email;
private int age;
private boolean active;
// Геттеры, сеттеры...
}
UserDao, мы просто создаем интерфейс.
public interface UserRepository extends JpaRepository<User, Long> {
// Здесь пусто! Но методы уже есть.
}
JpaRepository, вы сразу получаете готовые методы:.save(user) - сохранить/обновить..findById(id) - найти по ID (возвращает Optional)..findAll() - найти всех..deleteById(id) - удалить.
public interface UserRepository extends JpaRepository<User, Long> {
// SQL: SELECT * FROM users WHERE email = ?
Optional<User> findByEmail(String email);
// SQL: SELECT * FROM users WHERE active = true AND age > ?
List<User> findByActiveTrueAndAgeGreaterThan(int age);
// SQL: EXISTS (SELECT 1 FROM users WHERE email = ?)
boolean existsByEmail(String email);
}
find + By + ИмяПоля + Условие (если нужно).@Query)findByNameAndAgeAndActiveAnd...). Или нужен сложный JOIN.
@Query("SELECT u FROM User u WHERE u.email LIKE %:domain%")
List<User> findUsersByEmailDomain(@Param("domain") String domain);
@Transactional)@Transactional над методом сервиса.
@Service
public class PaymentService {
@Transactional // Если упадет ошибка, все изменения откатятся
public void transferMoney() {
repo.withdraw(...);
repo.deposit(...);
}
}
@Entity.extends JpaRepository.findByField.@Query.
🎮 Анатомия REST Controller: Входящие и Исходящие
Раньше, чтобы вернуть JSON, нужно было танцевать с бубном. В Spring Boot это делается "из коробки" благодаря библиотеке Jackson, которая тихо работает в фоне.
1️⃣ @RestController vs @Controller
Это первый вопрос на собеседовании.
🔴@Controller: Олдскул. Используется, когда мы возвращаем HTML-страницы (Thymeleaf, JSP). Чтобы вернуть JSON, нужно над каждым методом вешать @ResponseBody.
🔴@RestController: Современный стандарт для REST API.
🔴Это просто @Controller + @ResponseBody над всеми методами.
🔴Всё, что возвращает метод, автоматически превращается в JSON.
2️⃣ Принимаем данные (3 главных способа)
Как вытащить информацию из запроса?
А. Из пути URL (@PathVariable)
Используем, когда параметр - это часть адреса ресурса.
🔴URL: GET /users/42
🔴Код:
@GetMapping("/users/{id}")
public User getById(@PathVariable Long id) { ... }
@RequestParam)GET /users?role=ADMIN&age=25
@GetMapping("/users")
public List<User> search(
@RequestParam String role,
@RequestParam(required = false) Integer age // Опционально
) { ... }
@RequestBody){ "name": "Alex", "email": "a@b.com" }
@PostMapping("/users")
public User create(@RequestBody UserDto userDto) { ... }
ResponseEntity)User, это хорошо (статус будет 200 OK). Но что, если мы хотим вернуть 404 (Not Found) или 201 (Created)?ResponseEntity<T>.
@RestController
@RequestMapping("/api/v1/users") // Общий префикс для всех методов
public class UserController {
private final UserService service; // Внедряем через конструктор
public UserController(UserService service) {
this.service = service;
}
// 1. Получить всех (GET 200 OK)
@GetMapping
public List<User> getAll() {
return service.findAll();
}
// 2. Найти одного (с управлением статусом)
@GetMapping("/{id}")
public ResponseEntity<User> getOne(@PathVariable Long id) {
return service.findById(id)
.map(user -> ResponseEntity.ok(user)) // 200 OK
.orElse(ResponseEntity.notFound().build()); // 404 Not Found
}
// 3. Создать (POST 201 Created)
@PostMapping
public ResponseEntity<User> create(@RequestBody UserDto dto) {
User created = service.save(dto);
return ResponseEntity.status(HttpStatus.CREATED).body(created);
}
}
@JsonIgnore - поле не попадет в JSON.@JsonProperty("full_name") - поле fullName в Java станет full_name в JSON.@RestController для API.@PathVariable - для ID (/users/1).@RequestParam - для фильтров (/users?sort=name).@RequestBody - для больших данных (JSON).ResponseEntity, чтобы контролировать HTTP-статусы.
⌨️ Открытый урок «Неожиданное введение в Spring Context».
🗓 22 января в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «Разработчик на Spring Framework».
На очередном открытом уроке курса "Разработчик на Spring Framework", мы на примере своего приложения попробуем реализовать свой IoC-контейнер, которой отдаленно будет напоминать Spring Context
Кому будет интересно:
Начинающим Java-бэкенд-разработчикам.
Результаты после вебинара:
Поймете общую идею IoC/Spring IoC.
🔗 Ссылка на регистрацию: https://vk.cc/cTwZTO
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🧵 Виртуальные потоки: Революция производительности
Представьте, что вы строите высоконагруженный сервер. Раньше у вас было два пути:
1. Классика (Thread): Простой код, но один поток весит ~2 Мб памяти. Создадите 5,000 потоков - сервер упадет с OutOfMemoryError.
2. Асинхронность (WebFlux/Netty): Сервер держит 100k соединений, но код превращается в лапшу из callbacks и CompletableFuture, которую невозможно отлаживать.
В Java 21 появились Виртуальные потоки. Они объединяют простоту первого подхода и производительность второго.
🪶 В чем магия?
Классический поток Java (Platform Thread) привязан 1-к-1 к потоку операционной системы (OS Thread). Это дорогой ресурс.
Виртуальный поток, это просто объект в куче (heap) JVM. Он не привязан к ОС намертво.
🔴Вес: Несколько килобайт (вместо мегабайт).
🔴Количество: Можно создать миллион виртуальных потоков на обычном ноутбуке.
⚙️ Как это работает (Carrier Threads)
Под капотом работает схема Mount/Unmount:
1. JVM запускает небольшой пул обычных потоков ОС (называются Carrier Threads, обычно их число = числу ядер CPU).
2. Ваш виртуальный поток "садится верхом" на Carrier-поток и выполняет код.
3. ⚠️ Самое важное: Как только ваш код блокируется (ждет ответа от БД, читает файл, делает Thread.sleep), JVM снимает виртуальный поток с ядра.
4. Поток ОС освобождается и тут же берет в работу другой виртуальный поток.
Итог: Ядра процессора молотят на 100%, никогда не простаивая в ожидании ввода-вывода.
💻 Код: Найди 1 отличие
API практически не изменился. Вам не нужно учить новые фреймворки.
// Старый способ (Тяжелый поток ОС)
Thread.ofPlatform().start(() -> {
System.out.println("Я ем много памяти!");
});
// Новый способ (Легкий виртуальный поток)
Thread.ofVirtual().start(() -> {
System.out.println("Я ничего не вешу!");
});
// Использование с ExecutorService (для старого кода)
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
IntStream.range(0, 1_000_000).forEach(i -> {
executor.submit(() -> {
Thread.sleep(1000); // Блокировка теперь БЕСПЛАТНАЯ
return i;
});
});
}
// Этот код запустит миллион задач за секунду, не положив сервер.
var user = db.findUser();var data = http.sendRequest(user);
🎯 Открытый урок «Сетевой чат на C#».
🗓 22 января в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «C# Developer».
На вебинаре:
✔️ Рассмотрим написание сетевого приложения на C#.
✔️ Мы реализуем простые клиент и сервер с помощью одного из сетевых протоколов.
✔️Также затронем темы многопточности и асинхронности
Кому будет полезно:
- Вебинар будет полезен начинающим разработчикам, желающим разобраться в сетевом и многопочном\асинхронном программировании.
Что вы получите:
- По итогам вебинара смогут проектировать сетевые приложения.
- Получат представление о работе сетевых протоколов, и многопоточности\асинхронности в приложениях.
- На практике попробуют разработать такое приложение.
🔗 Ссылка на регистрацию: https://vk.cc/cTqyyY
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🧑💻Пишете на Vue и давно работаете с Vue Router по привычке? Сейчас в экосистеме появляется новая опция — Kitbag Router. Лёгкий повод пересобрать подход к роутингу и обновить стек.
На открытом уроке разберём, как подключить его к проекту, настроить под свой стек и чем он принципиально отличается от Vue Router. Пошагово пройдём путь от установки до рабочих маршрутов в SPA.
Вы познакомитесь с новой библиотекой роутинга для VueJS, научитесь создавать приложения с клиентским роутингом на Kitbag Router, сравнивать его с Vue Router и осознанно выбирать инструмент под задачу.
📆Встречаемся 21 января в 20:00 МСК в преддверие старта курса «Vue.js разработчик». Регистрация открыта: https://vk.cc/cTo0LX
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
💿 Java Records: Убийцы бойлерплейта
Сколько раз вы создавали класс просто чтобы "перенести данные" из точки А в точку Б?
Вы пишете 3 поля, а потом IDE генерирует вам 50 строк кода: конструктор, геттеры, equals, hashCode, toString... 🤯
В Java 16+ этому положили конец. Встречайте Records.
📉 Было vs Стало
Допустим, нам нужен простой DTO для пользователя.
❌ Классический POJO (Java 1.0 - 15):
public class User {
private final String name;
private final int age;
public User(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() { return name; }
public int getAge() { return age; }
// + equals()
// + hashCode()
// + toString() ... еще 30 строк кода
}
public record User(String name, int age) {}
record, вы автоматически получаете:private final).get! Просто .name(), .age()).equals() и hashCode() (идеально для ключей в Map или Set).toString() (красивый вывод: User[name=Alex, age=25]).
public record User(String name, int age) {
// Компактный конструктор
public User {
if (age < 0) {
throw new IllegalArgumentException("Возраст не может быть меньше 0");
}
// Присваивание this.age = age происходит автоматически!
}
}
extends) другой класс (потому что он уже наследует java.lang.Record). Но имплементировать интерфейсы (implements) можно!equals/hashCode.record.
🎁 Optional: Лекарство от NullPointerException
Тони Хоар назвал изобретение null своей "ошибкой на миллиард долларов". NullPointerException (NPE) - самый частый кошмар Java-разработчика.
В Java 8 появился Optional<T> - класс-обертка, который явно говорит: "Здесь значения может и не быть".
📦 Что внутри?
Представьте Optional как коробку.
🔴В ней может лежать объект (Non-empty).
🔴Или она может быть пустой (Empty).
Главное правило: Никогда не возвращайте null из метода, если можно вернуть Optional.empty().
🚫 Как делать НЕ надо
Самая частая ошибка новичка, использовать Optional как старый добрый if (x != null):
Optional<User> userOpt = findUser("Alex");
// ❌ ПЛОХО: Это тот же null-check, только сложнее
if (userOpt.isPresent()) {
System.out.println(userOpt.get().getName());
}
.get() - это зло. Если коробка пуста, он бросит NoSuchElementException, и вы просто поменяли шило (NPE) на мыло.Optional раскрывается, когда вы строите цепочки вызовов, как в стримах.ifPresent)
findUser("Alex").ifPresent(user -> System.out.println(user.getName()));
orElse)
// Вернет юзера или создаст нового "Guest", если не нашел
User user = findUser("Alex").orElse(new User("Guest"));
orElseThrow)
User user = findUser("Alex")
.orElseThrow(() -> new IllegalArgumentException("User not found"));
map)
String email = findUser("Alex")
.map(User::getEmail) // Достаем email (если юзер есть)
.map(String::toUpperCase) // В верхний регистр (если email был)
.orElse("UNKNOWN"); // Если хоть на одном этапе было пусто
Optional как тип поля в классе или аргумент метода. Это лишний оверхед и мусор в коде.orElse() vs orElseGet():orElse(new Object()) - объект создается всегда, даже если он не нужен.orElseGet(() -> new Object()) - объект создается только если в коробке пусто (лениво). Используйте этот вариант для тяжелых объектов.Optional спасает не тем, что убирает null, а тем, что заставляет вас явно обработать случай отсутствия значения..get(). Используйте .map(), .filter() и .orElse().
🛒 Collectors: Собираем урожай Stream API
Мы отфильтровали, преобразовали и отсортировали данные. Теперь их нужно сложить в коробочку, чтобы использовать дальше. Для этого существует терминальная операция .collect().
Внутрь нее мы передаем специальный объект - Collector. Чтобы не писать его вручную, в Java есть утилитный класс Collectors с готовыми решениями на все случаи жизни.
📦 Базовый набор (Must Have)
1. В список или множество
💙Collectors.toList() - собирает все в ArrayList (но тип не гарантирован).
💙Collectors.toSet() - собирает в HashSet (убирает дубликаты).
💙Java 16+ Update: Теперь можно просто писать .toList() прямо у стрима, без collect(...). Это создает неизменяемый список.
2. В строку (joining)
💙Больше не нужно мучиться с StringBuilder в циклах.
💙Collectors.joining(", ") - склеит строки через запятую.
🔑 Продвинутый уровень: Карты и Группировки
Самая мощная магия происходит здесь.
3. В Map (toMap)
Превращает список объектов в Map (ключ-значение).
💙Синтаксис: toMap(Function keyMapper, Function valueMapper)
💙Важно: Если ключи совпадут, вылетит IllegalStateException.
💙Лечение: Третий аргумент - "мердж-функция" (что делать при конфликте).
4. Группировка (groupingBy)
Аналог GROUP BY из SQL. Это киллер-фича Stream API.
💙Разделяет элементы на группы по какому-то признаку и кладет их в Map<Критерий, Список>.
💻 Примеры в коде
Представьте, у нас есть класс User(String name, String role).
List<User> users = List.of(
new User("Alex", "ADMIN"),
new User("Bob", "USER"),
new User("Charlie", "USER")
);
// 1. Склеиваем имена в одну строку
String names = users.stream()
.map(User::getName)
.collect(Collectors.joining(", "));
// Результат: "Alex, Bob, Charlie"
// 2. Превращаем в Map: Имя -> Роль
Map<String, String> userMap = users.stream()
.collect(Collectors.toMap(
User::getName, // Ключ
User::getRole // Значение
));
// Результат: {Alex=ADMIN, Bob=USER, Charlie=USER}
// 3. Группируем по Роли (SQL GROUP BY)
Map<String, List<User>> byRole = users.stream()
.collect(Collectors.groupingBy(User::getRole));
// Результат:
// {
// "ADMIN": [User(Alex)],
// "USER": [User(Bob), User(Charlie)]
// }
groupingBy можно передать второй коллектор! Например, чтобы не просто сгруппировать пользователей, а сразу посчитать их количество в каждой группе:
Map<String, Long> countByRole = users.stream()
.collect(Collectors.groupingBy(
User::getRole,
Collectors.counting() // Downstream collector
));
// Результат: {ADMIN=1, USER=2}
Collectors позволяют превратить поток данных в любую удобную структуру: от простого списка до сложной многоуровневой мапы.
А вы справитесь с тестом по HighLoad?
Как пройти путь от разработчика до архитектора высоконагруженных систем для работы с крупными проектами?
Пройдите тест, проверьте свои знания для обучения на курсе «Highload Architect» от OTUS. А так же и получите скидку 🎁 до 15.02.2026 - подробности у менеджера.
➡️ Пройти Тест https://vk.cc/cU6fLb
На курсе вы освоите проектирование масштабируемых и отказоустойчивых систем, оптимизацию производительности, работу с современными инструментами для создания высоконагруженных решений и лучшие практики разработки серверных приложений.
❗️Практическое обучение проводится в прямом эфире — вебинары не являются предзаписанными.
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🚀 Redis + Spring Cache: Турбо-наддув для бэкенда
Самая медленная часть любого приложения это ввод-вывод (I/O). Поход в базу данных (Postgres/MySQL) это "долго" (миллисекунды). Поход в оперативную память это "мгновенно" (наносекунды).
Redis - это база данных, которая хранит всё в оперативной памяти (In-Memory). Она идеально подходит на роль кэша.
🧠 Как работает Spring Cache?
Spring предоставляет крутую абстракцию. Вам не нужно писать код для подключения к Redis в каждом методе. Вы просто вешаете аннотации, а Spring сам перехватывает вызов метода.
Алгоритм @Cacheable:
1. Вызывается метод getUser(1).
2. Spring лезет в кэш (Redis) по ключу user::1.
3. Если данные есть (Cache Hit): Spring НЕ выполняет код метода, а сразу возвращает данные из кэша.
4. Если данных нет (Cache Miss): Spring выполняет метод (идет в БД), берет результат, кладет его в кэш и отдает вам.
🛠 Настройка (2 шага)
1. Зависимости
В pom.xml добавляем стартер для кэша и драйвер Redis:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
@EnableCaching.@Cacheable — "Запомни меня"get, find).
@Service
public class UserService {
@Cacheable(value = "users", key = "#id")
public User getUserById(Long id) {
// Имитация долгого запроса в БД (3 секунды)
simulateSlowService();
return userRepository.findById(id).orElseThrow();
}
}
@CacheEvict - "Забудь меня"
@CacheEvict(value = "users", key = "#id")
public void deleteUser(Long id) {
userRepository.deleteById(id);
}
getUserById(id) Spring увидит, что кэш пуст, и снова сходит в БД за свежими данными.@CachePut - "Обнови меня"ConcurrentHashMap прямо в Java?"HashMap съест всю память JVM, и приложение упадет (OutOfMemory). Redis живет отдельно.HashMap. Кэш будет рассинхронизирован. Redis это общий кэш для всех инстансов.HashMap очищается. Redis (обычно) работает на отдельном сервере и хранит данные даже при рестарте вашего кода.Serializable, либо (что правильнее) нужно настроить Jackson Serializer, чтобы хранить данные в Redis в читаемом JSON-формате.@Cacheable.@CacheEvict.
📨 Apache Kafka: Нервная система микросервисов
Представьте, что вы заказали пиццу.
🔴REST подход: Вы стоите у прилавка и смотрите на повара, пока он не закончит. Вы не можете отойти. Если повар уснул - вы застряли.
🔴Kafka подход: Вы бросаете чек в коробку "Заказы" и уходите по своим делам. Повар возьмет заказ, когда освободится. Когда пицца будет готова, он положит её на стол выдачи, и вы получите уведомление.
Kafka - это распределенный лог событий. Это не просто очередь, это история всего, что произошло в системе.
🧩 Основные понятия
1. Topic (Топик) - Это "папка" или канал, куда падают сообщения. Например: orders-topic, email-topic.
2. Producer (Продюсер) - Тот, кто пишет сообщения в топик (например, сервис Заказов).
3. Consumer (Консьюмер) - Тот, кто читает сообщения (например, сервис Уведомлений или Склад).
4. Broker (Брокер) - Сервер Kafka, который хранит эти данные.
🚀 Главная фишка: Fire and Forget
Когда OrderService создает заказ, ему плевать, работает ли сейчас сервис отправки SMS или сервис начисления бонусов.
Он просто кидает событие OrderCreated в Kafka и мгновенно возвращает ответ пользователю "Заказ принят".
Сервисы-подписчики (Consumers) разгребут эти сообщения в своем темпе. Если сервис SMS упал, он поднимется через час, прочитает топик с того места, где остановился, и дошлет все смски. Данные не пропадут.
💻 Spring Kafka: Как писать код?
В Spring Boot работа с Kafka максимально упрощена.
1. Настройка (application.yaml)
spring:
kafka:
bootstrap-servers: localhost:9092 # Адрес брокера
consumer:
group-id: my-group # Важно для масштабирования
KafkaTemplate.
@Service
@RequiredArgsConstructor
public class OrderProducer {
private final KafkaTemplate<String, String> kafkaTemplate;
public void sendOrderEvent(String orderId) {
// Отправляем в топик "orders"
kafkaTemplate.send("orders", orderId);
System.out.println("Сообщение отправлено: " + orderId);
}
}
@KafkaListener.
@Service
public class NotificationConsumer {
@KafkaListener(topics = "orders", groupId = "notification_group")
public void listen(String orderId) {
System.out.println("Получено событие для заказа: " + orderId);
// Тут логика отправки email/sms
sendEmail(orderId);
}
}
📦 От Кода к Продакшену: JAR и Docker
В старые времена (Java EE) процесс деплоя был адом: нужно было установить на сервер Tomcat, настроить его, скомпилировать .war файл, закинуть его в папку... 🤯
Spring Boot принес концепцию Fat JAR (Жирный JAR).
🍔 1. Fat JAR - "Всё своё ношу с собой"
Spring Boot упаковывает ваше приложение, все библиотеки (зависимости) и даже сам веб-сервер (Tomcat) в один единственный файл .jar.
Этот файл работает как .exe в Windows. Ему ничего не нужно, кроме установленной Java.
Как собрать?
В терминале (в папке проекта):
# Для Maven
./mvnw clean package
# Для Gradle
./gradlew build
target (или build/libs) появится файл myapp-0.0.1-SNAPSHOT.jar.
java -jar myapp.0.0.1-SNAPSHOT.jar
DockerfileDockerfile в корне проекта.
# 1. Берем базовый образ с Java 17 (легковесный Alpine Linux)
FROM eclipse-temurin:17-jre-alpine
# 2. Копируем наш JAR внутрь образа
# (Предварительно нужно сделать mvn package руками!)
COPY target/*.jar app.jar
# 3. Говорим, какую команду запустить при старте контейнера
ENTRYPOINT ["java", "-jar", "/app.jar"]
# 1. Собираем образ (Image)
docker build -t my-spring-app .
# 2. Запускаем контейнер
# -p 8080:8080 пробрасывает порт наружу
docker run -p 8080:8080 my-spring-app
# --- Этап 1: Сборка (Build) ---
FROM maven:3.8.5-openjdk-17 AS builder
WORKDIR /app
COPY . .
# Собираем JAR, пропуская тесты (для скорости)
RUN mvn clean package -DskipTests
# --- Этап 2: Запуск (Run) ---
# Берем чистый, маленький образ для запуска
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
# Копируем ТОЛЬКО готовый jar из первого этапа
COPY --from=builder /app/target/*.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]
docker build, даже если на компьютере вообще не установлена Java!
🎥 Открытый урок «Apache Camel: масштабируемые интеграции для Highload».
🗓 28 января в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «Java Developer. Advanced».
Как сделать так, чтобы ваши интеграции на Camel не стали узким местом при росте нагрузки?
🚑 Global Exception Handling: Красиво падаем
Представьте: пользователь запрашивает ID, которого нет.
🔴Плохой сценарий: Сервер выплевывает стэктрейс на 500 строк, раскрывая внутренности БД. Статус 500 Internal Server Error. Клиент в шоке.
🔴Хороший сценарий: Клиент получает аккуратный JSON: {"status": 404, "message": "User not found"}.
Раньше, чтобы добиться хорошего сценария, приходилось писать try-catch в каждом методе контроллера. Это ужасно.
В Spring Boot есть элегантное решение - @ControllerAdvice.
🛡 Что это такое?
Это перехватчик (Interceptor), который работает по принципу Аспектно-Ориентированного Программирования (AOP). Он "сидит" над всеми вашими контроллерами и ловит исключения, которые вылетели из них, прежде чем они дойдут до пользователя.
🛠 Как настроить? (3 шага)
1. Создаем DTO для ошибки
Нам нужен красивый формат ответа, чтобы фронтенд всегда знал, чего ожидать.
public record ErrorResponse(int statusCode, String message, LocalDateTime timestamp) {}
@RestControllerAdvice. Это тот же @ControllerAdvice, но он автоматически добавляет @ResponseBody ко всем ответам (мы же пишем REST API).@ExceptionHandler.
@RestControllerAdvice
public class GlobalExceptionHandler {
// 1. Ловим конкретную ошибку (например, сущность не найдена)
@ExceptionHandler(EntityNotFoundException.class)
public ResponseEntity<ErrorResponse> handleNotFound(EntityNotFoundException ex) {
return ResponseEntity
.status(HttpStatus.NOT_FOUND)
.body(new ErrorResponse(404, ex.getMessage(), LocalDateTime.now()));
}
// 2. Ловим ошибки валидации (если передали кривой JSON)
@ExceptionHandler(MethodArgumentNotValidException.class)
public ResponseEntity<ErrorResponse> handleValidation(MethodArgumentNotValidException ex) {
String errors = ex.getBindingResult().getFieldErrors().stream()
.map(e -> e.getField() + ": " + e.getDefaultMessage())
.collect(Collectors.joining(", "));
return ResponseEntity
.status(HttpStatus.BAD_REQUEST)
.body(new ErrorResponse(400, errors, LocalDateTime.now()));
}
// 3. Ловим всё остальное (Fallback)
@ExceptionHandler(Exception.class)
public ResponseEntity<ErrorResponse> handleAll(Exception ex) {
return ResponseEntity
.status(HttpStatus.INTERNAL_SERVER_ERROR)
.body(new ErrorResponse(500, "Произошла внутренняя ошибка", LocalDateTime.now()));
}
}
public User getUser(Long id) {
return repo.findById(id)
.orElseThrow(() -> new EntityNotFoundException("User with id " + id + " not found"));
}
try-catch блоков. Только "счастливый путь" (happy path).try-catch в контроллерах.@RestControllerAdvice.EntityNotFoundException) на HTTP-статусы (404 Not Found).
🔴 Завтра тестовое собеседование с Java-разработчиком
21 января(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Java-разработчика.
Как это будет:
📂 Сергей Чамкин, старший разработчик из Uzum, ex-WildBerries, будет задавать реальные вопросы и задачи разработчику-добровольцу
📂 Cергей будет комментировать каждый ответ респондента, чтобы дать понять чего от вас ожидает собеседующий на интервью
📂 В конце можно будет задать любой вопрос Сергею
Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.
Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot
Реклама.
О рекламодателе.
🧙♂️ Spring Boot: Магия под капотом (Starters & AutoConfig)
Вы когда-нибудь задумывались: почему вы просто добавляете одну строчку в pom.xml, пишете main метод, и у вас волшебным образом поднимается Tomcat, настраивается JSON-конвертер и подключается логирование?
За этим стоят два кита Spring Boot: Starters и AutoConfiguration.
1️⃣ Starters (Стартеры) - "Всё включено"
В старом Spring, чтобы сделать веб-приложение, нужно было вручную найти версии для Spring MVC, Tomcat, Jackson, Validation API... и молиться, чтобы они были совместимы.
Starter — это готовый набор зависимостей (dependencies), собранный в один пакет. Это как "Комбо-обед" в ресторане.
🔴Хотите Веб? Добавляете spring-boot-starter-web.
* Внутри: Tomcat + Spring MVC + Jackson + Logback.
🔴Хотите Тесты? Добавляете spring-boot-starter-test.
*Внутри: JUnit + Mockito + AssertJ + Hamcrest.
Вам больше не нужно думать о версиях библиотек. Spring Boot следит за "BOM" (Bill of Materials) и гарантирует, что все версии внутри стартера дружат друг с другом.
2️⃣ AutoConfiguration - "Умный детектив"
Это мозг фреймворка. Когда приложение запускается, Spring Boot начинает сканировать ваш classpath (все подключенные библиотеки jar).
Он рассуждает примерно так:
1. "Так, я вижу, что в зависимостях есть класс H2Driver?" "Значит, программист хочет базу данных. Создам-ка я ему бин DataSource с настройками для H2!"
2. "Я вижу классы Tomcat и Spring MVC?" "Значит, нужно поднять встроенный веб-сервер на порту 8080 и настроить DispatcherServlet."
3. "О, программист сам создал свой бин DataSource?" "Окей, тогда я отступаю и свою автоконфигурацию не применяю."
Вся эта логика держится на аннотациях @Conditional...:
🔴@ConditionalOnClass: Создать бин, если найден класс X.
🔴@ConditionalOnMissingBean: Создать бин, ТОЛЬКО если программист не создал такой же сам.
⚙️ Главная кнопка: @SpringBootApplication
Вы вешаете эту аннотацию над main классом. На самом деле это "матрешка", внутри которой спрятаны 3 другие аннотации:
@SpringBootConfiguration // Говорит: "Это конфигурационный класс"
@EnableAutoConfiguration // Говорит: "ВКЛЮЧИ МАГИЮ!" (запусти сканирование classpath)
@ComponentScan // Говорит: "Ищи пользовательские бины в этом пакете"
public @interface SpringBootApplication { ... }
application.properties одну строчку:
debug=true
🍃 Spring Boot: Магия или Логика? (IoC & Beans)
Когда вы запускаете Spring-приложение, происходит магия: все нужные объекты создаются сами, базы данных подключаются, сервер стартует.
Но за этой магией стоит четкий механизм - IoC Container (Inversion of Control / Инверсия управления).
📦 Что такое Application Context?
Представьте Spring как огромный завод.
🔴Context (Контейнер) - это сам завод. Он управляет жизненным циклом объектов.
🔴Bean (Бин) - это любая деталь (объект), которую этот завод создал и хранит у себя на складе.
Суть IoC:
🔴Обычный подход: Вы сами управляете объектами (Service s = new Service()). Вы - главный.
🔴Spring подход: Вы отдаете управление фреймворку. "Спринг, создай мне сервис и дай его, когда он понадобится". Spring - главный.
🏷 Как сделать Бин? (Аннотации)
Чтобы Spring узнал про ваши классы, их нужно пометить.
1. @Component — Самая базовая аннотация. "Эй, Спринг, это бин, управляй им!".
2. @Service - Тот же @Component, но семантически говорит: "Здесь бизнес-логика".
3. @Repository - Тот же @Component, но для работы с БД (ловит специфичные ошибки баз данных).
4. @Controller / @RestController - Для обработки HTTP-запросов.
5. @Configuration + @Bean - Используется, когда нужно создать бин из чужого класса (библиотеки), код которого вы не можете пометить аннотацией @Component.
💉 Dependency Injection (DI)
Главная фишка. Как один бин попадает внутрь другого?
Например, UserService нуждается в UserRepository.
❌ Способ 1: Через поле (Field Injection)
@Service
public class UserService {
@Autowired // ⚠️ Не рекомендуется!
private UserRepository repository;
}
NullPointerException.
@Service
public class UserService {
private final UserRepository repository;
// @Autowired здесь не обязателен (в новых версиях Spring)
public UserService(UserRepository repository) {
this.repository = repository;
}
}
final (неизменяемое), легко тестировать (можно передать любой репозиторий в конструктор), сразу видно все зависимости класса.
@Service
@RequiredArgsConstructor // Генерирует конструктор для final полей
public class UserService {
private final UserRepository repository; // Всё внедрится само!
}
new Service().@Service, @Repository).
🔒 Sealed Classes: Архитектурный фейсконтроль
В ООП всегда была проблема с наследованием. Либо ваш класс открыт для всех («Наследуйся кто хочет!»), либо он закрыт наглухо (final).
Но что, если я хочу, чтобы мой класс Shape (Фигура) могли наследовать только Circle и Square, и больше никто?
Раньше это решалось костылями (пакетная видимость, скрытые конструкторы). В Java 17 появился официальный механизм: Sealed Classes.
🚧 Как это работает?
Вы помечаете класс (или интерфейс) ключевым словом sealed и после слова permits перечисляете тех, кому "можно".
// Родитель: Разрешает наследование ТОЛЬКО этим двум классам
public sealed interface Payment
permits CreditCard, Cash {
}
class Crypto extends Payment, компилятор ударит его по рукам. 🚫final - Цепочка наследования обрывается. Дальше наследовать нельзя.
public final class Cash implements Payment { ... }
sealed - Иерархия продолжается, но снова под контролем.
public sealed class CreditCard implements Payment permits Visa, MasterCard { ... }
non-sealed - "Открываем шлюзы". Дальше от этого класса может наследоваться кто угодно (возврат к старому поведению Java).
public non-sealed class DebitCard implements Payment { ... }
sealed иерархию в новом switch, компилятор знает все возможные варианты.default!
// Метод обработки платежа
String process(Payment p) {
return switch (p) {
case CreditCard c -> "Processing card: " + c.getNumber();
case Cash c -> "Processing cash amount: " + c.getAmount();
// default НЕ НУЖЕН! Компилятор знает, что третьго не дано.
};
}
permits новый класс Crypto, код перестанет компилироваться, пока вы не обработаете этот новый кейс в свитче.
🔮 Pattern Matching в Switch: Типизируй это!
Помните этот бесконечный кошмар, когда вам приходит Object, и нужно понять, что внутри?
Раньше мы писали "лестницу" из if-else и instanceof с кучей ручного кастинга (приведения типов).
❌ Было (Боль и слезы):
Object obj = getUnknownObject();
if (obj instanceof String) {
String s = (String) obj; // Ручной каст
System.out.println("Строка: " + s.length());
} else if (obj instanceof Integer) {
Integer i = (Integer) obj; // Опять каст
System.out.println("Число: " + i);
} else if (obj instanceof Long) {
// ... и так до бесконечности
}
switch умеет проверять типы! Больше никаких instanceof и ручных приведений. Переменная создается прямо в кейсе.
switch (obj) {
case String s -> System.out.println("Строка: " + s.length());
case Integer i -> System.out.println("Число: " + i);
case Long l -> System.out.println("Длинное число: " + l);
default -> System.out.println("Непонятно что");
}
if внутри case. Теперь у нас есть ключевое слово when.
switch (obj) {
// Попадет сюда, ТОЛЬКО если это строка И она длиннее 10 символов
case String s when s.length() > 10 ->
System.out.println("Длинная строка: " + s);
// Любая другая строка
case String s ->
System.out.println("Короткая строка: " + s);
case Integer i ->
System.out.println("Число: " + i);
default -> {}
}
switch, если передать null, мы мгновенно получали NullPointerException.switch можно (и нужно!) обрабатывать null легально:
switch (obj) {
case String s -> System.out.println("Это строка");
case null -> System.out.println("Пришел null!"); // Никакого NPE
default -> System.out.println("Что-то другое");
}
animal.makeSound()), то теперь можно собирать логику обработки разных типов в одном месте, что часто бывает удобнее при написании бизнес-логики (например, обработка разных типов ивентов или DTO).Switch теперь принимает любые объекты.case String s).when.null.
🔀 Switch Expressions: Прощай, break!
Помните это чувство, когда забыл написать break в switch-case, и код пошел выполняться дальше, создав неуловимый баг? 😫
В современных версиях Java (стандарт с Java 14) оператор switch прокачали. Теперь это не просто управляющая конструкция, а выражение, возвращающее результат.
💀 Было (Statement)
Громоздко, опасно (fall-through), переменная вынесена наружу.
DayOfWeek day = DayOfWeek.SATURDAY;
int numLetters;
switch (day) {
case MONDAY:
case FRIDAY:
case SUNDAY:
numLetters = 6;
break; // Забыл break? Получи баг!
case TUESDAY:
numLetters = 7;
break;
default:
throw new IllegalStateException("Wat: " + day);
}
int numLetters = switch (day) {
case MONDAY, FRIDAY, SUNDAY -> 6;
case TUESDAY -> 7;
default -> throw new IllegalStateException("Wat: " + day);
};
->)break больше писать не надо!switch теперь работает как формула. Вы можете сразу присвоить результат переменной или вернуть его из метода (return switch(...)).case MONDAY, FRIDAY, SUNDAY — просто перечисляем через запятую.yieldcase нужно не просто вернуть число, а выполнить несколько строк кода (например, залоггировать)?yield.return использовать нельзя, так как он прервет выполнение всего метода, а не только свича.
String result = switch (day) {
case SATURDAY, SUNDAY -> "Выходной";
case MONDAY -> {
System.out.println("Тяжелый день...");
yield "Будни"; // yield возвращает значение из switch
}
default -> "Будни";
};
switch по Enum, компилятор проверит, все ли варианты вы обработали. Если добавите в Enum новый день, а в свич - нет, код просто не скомпилируется. Это отличная защита от забывчивости!switch это чистый кайф. Он делает код компактнее и убирает целый класс ошибок, связанных с пропущенными break.->, когда нужно просто сопоставить значение.yield, если нужна логика внутри блока.
⌨️ Открытый урок «Spring AI: от изображения к данным. Практика распознавания документов».
🗓 15 января в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «Разработчик на Spring Framework».
На вебинаре:
✔️ Введение в Spring AI для обработки документов.
✔️ Настройка проекта: зависимости и конфигурация модели.
✔️ Ключевые концепции: работа с изображениями, системные промпты, OutputParser.
✔️ Сервисный слой: оркестрация шагов AI-пайплайна.
✔️ REST API для загрузки/анализа, обработка ошибок и масштабирование.
Кому будет интересно:
Java-разработчикам на Spring, backend-инженерам, архитекторам и тимлидам, которым нужно встроить распознавание документов в сервисы.
Результаты после вебинара:
Соберете простой пайплайн: загрузка изображения → извлечение текста → JSON. Поймете, где в Spring AI применять промпты и OutputParser.
🔗 Ссылка на регистрацию: https://vk.cc/cTkeIQ
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🎯 Открытый урок «Linq на практике».
🗓 14 января в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «C# Developer».
На вебинаре будут рассмотрены:
✔️ синтаксис операторов linq;
✔️синтаксис компараторов, применяемых в linq-запросах;
✔️примеры linq-запросов для наиболее популярных коллекций.
Кому будет полезно:
- данная тема будет интересна всем, кто работает с массивами данных в рамках .NET. Вы сможете эффективно использовать простой синтаксис для наиболее частых операций применяемых в рамках работы с коллекциями.
Что вы получите:
- вы сможете писать свои linq-запросы, опираясь на синтаксис linq.Будете знать разницу при применении тех или иных методов в рамках написания linq-запросов.
🔗 Ссылка на регистрацию: https://vk.cc/cTdPQ7
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🚀 В чем разница между HashMap и Hashtable в Java?
Если вы работаете с Java, то наверняка сталкивались с HashMap и Hashtable. Оба используются для хранения пар "ключ-значение", но между ними есть важные различия. Давайте разберемся!
1. Синхронизация (Потокобезопасность)
- Hashtable:
- Синхронизирован (потокобезопасен). Все его методы синхронизированы, то есть только один поток может работать с ним одновременно.
- Это делает Hashtable безопасным для многопоточных сред, но может снижать производительность в однопоточных сценариях.
- HashMap:
- Не синхронизирован (не потокобезопасен). Несколько потоков могут обращаться к нему одновременно, что может привести к проблемам в многопоточных средах.
- Для потокобезопасности можно использовать Collections.synchronizedMap(new HashMap<>()) или ConcurrentHashMap.
2. Null-ключи и Null-значения
- Hashtable:
- Не позволяет использовать null в качестве ключа или значения. Попытка добавить null вызовет NullPointerException.
- HashMap:
- Разрешает один null - ключ и множество null -значений.
3. Производительность
- Hashtable:
- Медленнее из-за накладных расходов на синхронизацию.
- HashMap:
- Быстрее в однопоточных средах, так как не синхронизирован.
4. Наследие
- Hashtable:
- Считается устаревшим классом (появился в Java 1.0). Не является частью Java Collections Framework.
- HashMap:
- Часть Java Collections Framework (появился в Java 1.2). Более современный и широко используемый.
5. Итерация
- Hashtable:
- Использует Enumeration для перебора ключей и значений.
- HashMap:
- Использует Iterator, который более гибкий и позволяет удалять элементы во время перебора.
6. Наследование
- Hashtable:
- Наследуется от класса Dictionary (абстрактный класс, который сейчас считается устаревшим).
- HashMap:
- Наследуется от AbstractMap, который является частью Java Collections Framework.
7. Рекомендации по использованию
- Используйте HashMap, если:
- Работаете в однопоточной среде.
- Нужна высокая производительность.
- Требуется поддержка null-ключей или значений.
- Используйте Hashtable, если:
- Нужна потокобезопасность в многопоточной среде.
- Однако в современной Java ConcurrentHashMap предпочтительнее, так как он обеспечивает лучшую производительность и масштабируемость.
Пример кода Hashtable:
Hashtable<String, Integer> hashtable = new Hashtable<>();
hashtable.put("one", 1);
hashtable.put("two", 2);
// hashtable.put(null, 3); // Выбросит NullPointerException
System.out.println(hashtable);
HashMap:
HashMap<String, Integer> hashMap = new HashMap<>();
hashMap.put("one", 1);
hashMap.put("two", 2);
hashMap.put(null, 3); // Разрешено
System.out.println(hashMap);
Hashtable | HashMap |Enumeration | Iterator |Dictionary | Наследует AbstractMap |HashMap используется чаще. Если нужна потокобезопасность, лучше выбрать ConcurrentHashMap, а не Hashtable.