👨💻
Structured Concurrency в Java 26 — шестое превью. JEP 525.Проблема, которую решает эта фича, хорошо знакома любому, кто писал параллельный код на Java.
ExecutorService,
Future,
CompletableFuture ничего не знают о связях между задачами. Три параллельные подзадачи для одного запроса живут в разных потоках без общего «родителя» — и если одна упала, об этом никто
автоматически не узнает.
Классический пример: параллельно загружаем профиль, настройки и историю пользователя.
public class UnstructuredExample {
public static UserData loadUserData(int userId) {
String profile = fetchProfile(userId);
String preferences = fetchPreferences(userId);
String history = fetchHistory(userId);
return new UserData(profile, preferences, history);
}
}
Можно, конечно, попробовать добиться этого поведения вручную: добавить
cancel() в
catch, завернуть всё в
CompletableFuture.allOf, аккуратно обработать
CompletionException. Но очень легко сделать что-то не так. И чем больше задач — тем больше бойлерплейта, который всё равно не даёт нормальной иерархии, нормальных стектрейсов и легко читаемого кода.
Structured Concurrency решает это на уровне API.
public class StructuredExample {
public static UserData loadUserData(int userId) {
try (var scope = StructuredTaskScope.open(
StructuredTaskScope.Joiner.allSuccessfulOrThrow(),
Configuration cfg -> cfg
.withTimeout(Duration.ofSeconds(5))
.withName("load-user-data"))) {
// Fork all three subtasks — they run concurrently
var profile = scope.fork(() -> fetchProfile(userId));
var preferences = scope.fork(() -> fetchPreferences(userId));
var history = scope.fork(() -> fetchHistory(userId));
scope.join();
return new UserData(profile.get(),
preferences.get(),
history.get()
);
} catch (StructuredTaskScope.FailedException e) {
throw new RuntimeException("Failed to load user data: " + e.getCause().getMessage(), e);
}
}
}
Согласитесь, круто? Если любая задача упала — остальные отменяются автоматически. Поток-владелец гарантированно переживает все дочерние. Стектрейсы отражают реальную иерархию вызовов. Время жизни задач привязано к лексическому блоку — как
try-with-resources. И, что самое главное, описанное выше поведение можно довольно легко настроить.
Данная функциональность, на самом деле, с нами уже довольно давно. А что же поменялось в Java 26 по сравнению с Java 25?
— скоуп создаётся через статический
StructuredTaskScope.open() вместо
new— join() возвращает
List вместо
Stream — результаты материализованы сразу, без риска обратиться к ним после закрытия скоупа
— добавился
joinUntil(deadline) — если задачи не успели к дедлайну, скоуп их отменяет
API явно стабилизируется, но одному Гослингу известно сколько еще итераций preview ждёт эта фича 🙂
Подробнее про Java 26 можно почитать и посмотреть в отдельном видео и статье на Хабре.@spring_aio
