Интеграция с Consul
Consul предоставляет более богатые возможности для service discovery и health checking:
Consul теги могут использоваться для реализации сложной логики маршрутизации:
#Java #middle #Spring_Cloud_Gateway
Consul предоставляет более богатые возможности для service discovery и health checking:
spring:
cloud:
consul:
host: localhost
port: 8500
discovery:
health-check-path: /actuator/health
health-check-interval: 10s
tags:
- gateway-enabled
- version=v2
query-passing: true # Использовать только здоровые инстансы
gateway:
discovery:
locator:
enabled: true
predicates:
- name: Path
args:
pattern: "'/consul/' + serviceId + '/**'"
filters:
- name: RewritePath
args:
regexp: "'/consul/' + serviceId + '/(?<remaining>.*)'"
replacement: "'/${remaining}'"
# Фильтрация по Consul-тегам
include-expression: tags.contains('gateway-enabled')
Consul теги могут использоваться для реализации сложной логики маршрутизации:
@Bean
public RouteLocator consulTagBasedRoutes(
RouteLocatorBuilder builder,
ConsulDiscoveryClient discoveryClient) {
return builder.routes()
.route("canary_route", r -> r
.path("/api/canary/**")
.predicate(exchange -> {
// Динамическая канареечная маршрутизация
List<ServiceInstance> instances = discoveryClient
.getInstances("product-service");
// Выбор инстансов с тегом canary
ServiceInstance canaryInstance = instances.stream()
.filter(inst -> inst.getMetadata()
.getOrDefault("canary", "false")
.equals("true"))
.findFirst()
.orElse(null);
// 10% трафика на canary
return canaryInstance != null &&
Math.random() < 0.1;
})
.uri("lb://product-service")
)
.build();
}
#Java #middle #Spring_Cloud_Gateway
👍2
Кастомный RouteDefinitionRepository
Для полностью динамической маршрутизации можно реализовать собственный RouteDefinitionRepository, который будет загружать маршруты из произвольного источника (БД, файловая система, внешний сервис).
Базовая реализация с поддержкой обновлений:
Реализация с поддержкой веб-интерфейса для управления маршрутами:
#Java #middle #Spring_Cloud_Gateway
Для полностью динамической маршрутизации можно реализовать собственный RouteDefinitionRepository, который будет загружать маршруты из произвольного источника (БД, файловая система, внешний сервис).
Базовая реализация с поддержкой обновлений:
@Component
public class DatabaseRouteDefinitionRepository
implements RouteDefinitionRepository, ApplicationEventPublisherAware {
private final RouteDefinitionDAO routeDefinitionDAO;
private final Map<String, RouteDefinition> cache =
new ConcurrentHashMap<>();
private ApplicationEventPublisher publisher;
public DatabaseRouteDefinitionRepository(
RouteDefinitionDAO routeDefinitionDAO) {
this.routeDefinitionDAO = routeDefinitionDAO;
loadRoutes();
}
@Override
public Flux<RouteDefinition> getRouteDefinitions() {
return Flux.fromIterable(cache.values());
}
@Override
public Mono<Void> save(Mono<RouteDefinition> route) {
return route.flatMap(routeDef -> {
return routeDefinitionDAO.save(routeDef)
.doOnSuccess(saved -> {
cache.put(saved.getId(), saved);
publishRefreshEvent();
})
.then();
});
}
@Override
public Mono<Void> delete(Mono<String> routeId) {
return routeId.flatMap(id -> {
return routeDefinitionDAO.delete(id)
.doOnSuccess(deleted -> {
cache.remove(id);
publishRefreshEvent();
})
.then();
});
}
private void loadRoutes() {
routeDefinitionDAO.findAll()
.doOnNext(routeDef -> cache.put(routeDef.getId(), routeDef))
.subscribe();
}
private void publishRefreshEvent() {
if (publisher != null) {
publisher.publishEvent(
new RefreshRoutesEvent(this)
);
}
}
@Override
public void setApplicationEventPublisher(
ApplicationEventPublisher publisher) {
this.publisher = publisher;
}
// Метод для внешних триггеров обновления
@Scheduled(fixedDelay = 30000)
public void refreshRoutes() {
loadRoutes();
publishRefreshEvent();
}
}
Реализация с поддержкой веб-интерфейса для управления маршрутами:
@RestController
@RequestMapping("/api/gateway/routes")
public class RouteManagementController {
private final RouteDefinitionWriter routeDefinitionWriter;
private final RouteDefinitionLocator routeDefinitionLocator;
@PostMapping
public Mono<ResponseEntity<Void>> createRoute(
@RequestBody RouteDefinition routeDefinition) {
return routeDefinitionWriter
.save(Mono.just(routeDefinition))
.then(Mono.just(ResponseEntity.ok().build()));
}
@GetMapping
public Flux<RouteDefinition> getAllRoutes() {
return routeDefinitionLocator.getRouteDefinitions();
}
@PutMapping("/{id}")
public Mono<ResponseEntity<Void>> updateRoute(
@PathVariable String id,
@RequestBody RouteDefinition routeDefinition) {
return routeDefinitionWriter
.delete(Mono.just(id))
.then(routeDefinitionWriter.save(Mono.just(routeDefinition)))
.then(Mono.just(ResponseEntity.ok().build()));
}
@DeleteMapping("/{id}")
public Mono<ResponseEntity<Void>> deleteRoute(@PathVariable String id) {
return routeDefinitionWriter
.delete(Mono.just(id))
.then(Mono.just(ResponseEntity.noContent().build()));
}
}
#Java #middle #Spring_Cloud_Gateway
👍2
Интеграция с внешними системами конфигурации:
Обработка событий обновления маршрутов:
#Java #middle #Spring_Cloud_Gateway
@Component
public class ExternalConfigRouteDefinitionRepository
implements RouteDefinitionRepository {
private final ConfigClient configClient;
private final AtomicReference<List<RouteDefinition>> cachedRoutes =
new AtomicReference<>(Collections.emptyList());
public ExternalConfigRouteDefinitionRepository(
ConfigClient configClient) {
this.configClient = configClient;
configClient.watchRoutes()
.doOnNext(this::updateRoutes)
.subscribe();
}
@Override
public Flux<RouteDefinition> getRouteDefinitions() {
return Flux.fromIterable(cachedRoutes.get());
}
private void updateRoutes(List<RouteConfig> routeConfigs) {
List<RouteDefinition> routeDefinitions = routeConfigs.stream()
.map(this::convertToRouteDefinition)
.collect(Collectors.toList());
cachedRoutes.set(routeDefinitions);
// Генерация события обновления маршрутов
SpringApplication.publishEvent(
new RefreshRoutesEvent(this)
);
}
private RouteDefinition convertToRouteDefinition(
RouteConfig config) {
RouteDefinition definition = new RouteDefinition();
definition.setId(config.getId());
definition.setUri(URI.create(config.getUri()));
// Конвертация предикатов
config.getPredicates().forEach((name, args) -> {
PredicateDefinition predicate = new PredicateDefinition();
predicate.setName(name);
predicate.setArgs(args);
definition.getPredicates().add(predicate);
});
// Конвертация фильтров
config.getFilters().forEach((name, args) -> {
FilterDefinition filter = new FilterDefinition();
filter.setName(name);
filter.setArgs(args);
definition.getFilters().add(filter);
});
definition.setMetadata(config.getMetadata());
return definition;
}
@Override
public Mono<Void> save(Mono<RouteDefinition> route) {
// Делегирование сохранения во внешнюю систему
return route.flatMap(routeDef ->
configClient.saveRoute(convertToRouteConfig(routeDef))
).then();
}
@Override
public Mono<Void> delete(Mono<String> routeId) {
return routeId.flatMap(id ->
configClient.deleteRoute(id)
).then();
}
}
Обработка событий обновления маршрутов:
@Component
public class RouteUpdateListener {
private final RouteRefreshListener routeRefreshListener;
@EventListener
public void handleRefreshRoutesEvent(RefreshRoutesEvent event) {
// Логирование обновления маршрутов
logger.info("Routes refreshed by {}", event.getSource());
// Метрики
meterRegistry.counter("gateway.routes.refresh").increment();
// Уведомление подписчиков
routeRefreshListener.notifyRefresh();
}
@EventListener
public void handleApplicationEvent(ApplicationEvent event) {
if (event instanceof InstanceRegisteredEvent) {
// Обработка регистрации нового инстанса
updateRoutesForNewInstance(
((InstanceRegisteredEvent) event).getInstance()
);
}
}
}
#Java #middle #Spring_Cloud_Gateway
👍2
Глава 6. Итераторы
Интерфейс Iterator — фундаментальный механизм обхода коллекций
Итераторы представляют собой один из наиболее элегантных и мощных паттернов проектирования в программировании, обеспечивающий унифицированный способ последовательного доступа к элементам коллекций без раскрытия их внутреннего устройства. В Java интерфейс Iterator<E> служит стандартизированным контрактом для обхода любых коллекций, независимо от их внутренней реализации. Этот механизм не только упрощает код, но и обеспечивает абстракцию, позволяя алгоритмам работать с различными структурами данных единообразно.
Философия итераторов
Итераторы воплощают принцип единственной ответственности — отделяют логику обхода элементов от самих коллекций.
Это разделение позволяет:
Изменять внутреннее устройство коллекций, не затрагивая клиентский код
Обеспечивать единый интерфейс для работы с разнородными структурами данных
Реализовывать ленивую инициализацию и отложенную загрузку элементов
Поддерживать безопасное удаление элементов во время обхода
Архитектура интерфейса Iterator
Интерфейс Iterator<E> определен в пакете java.util и содержит три фундаментальных метода:
Каждый из этих методов играет критически важную роль в процессе итерации и имеет свою собственную семантику и особенности реализации.
Метод hasNext(): Проверка наличия следующего элемента
Метод hasNext() выполняет предикативную функцию — определяет, существуют ли еще элементы для обхода в коллекции. Этот метод является безопасным и идемпотентным, что означает возможность его многократного вызова без побочных эффектов.
Семантика и поведение
Детерминированность: Метод всегда возвращает однозначный результат — true или false, без промежуточных состояний.
Отсутствие побочных эффектов: Вызов hasNext() не модифицирует состояние итератора и не перемещает указатель текущей позиции.
Инвариантность: Результат метода зависит исключительно от внутреннего состояния итератора и коллекции на момент вызова.
Внутренние механизмы реализации
Для коллекций с известным размером (ArrayList, HashSet)
В коллекциях, где количество элементов известно заранее или может быть быстро вычислено, реализация hasNext() обычно сводится к простому сравнению:
Оптимизации:
Кэширование размера коллекции для избежания повторных вычислений
Флаги для отслеживания структурных изменений коллекции
Минимальные проверки для максимизации производительности
Для ленивых или потоковых коллекций
В случаях, когда элементы генерируются на лету или загружаются отложенно, реализация hasNext() может быть более сложной:
Проверка наличия данных в буфере
Запрос к внешнему источнику данных
Ожидание генерации следующего элемента
Обработка возможных исключений
Для структур данных со сложной навигацией (TreeMap, LinkedList)
В итераторах для сложных структур реализация hasNext() требует анализа внутреннего состояния:
Проверка достижения листовых узлов в деревьях
Анализ ссылок в связных списках
Учет особенностей обхода для конкретного алгоритма (in-order, pre-order, post-order)
Особенности производительности
Временная сложность: В большинстве реализаций hasNext() выполняется за O(1) время, так как требует только проверки условий без обхода структур.
Потребление памяти: Метод не создает новых объектов и использует минимальное количество временных переменных.
Thread-safety: В стандартных реализациях hasNext() не является потокобезопасным методом. Concurrent модификации коллекции могут привести к неконсистентным результатам.
Паттерны использования
Классический цикл обхода
Защита от пустых коллекций
#Java #для_новичков #beginner #Iterator
Интерфейс Iterator — фундаментальный механизм обхода коллекций
Итераторы представляют собой один из наиболее элегантных и мощных паттернов проектирования в программировании, обеспечивающий унифицированный способ последовательного доступа к элементам коллекций без раскрытия их внутреннего устройства. В Java интерфейс Iterator<E> служит стандартизированным контрактом для обхода любых коллекций, независимо от их внутренней реализации. Этот механизм не только упрощает код, но и обеспечивает абстракцию, позволяя алгоритмам работать с различными структурами данных единообразно.
Философия итераторов
Итераторы воплощают принцип единственной ответственности — отделяют логику обхода элементов от самих коллекций.
Это разделение позволяет:
Изменять внутреннее устройство коллекций, не затрагивая клиентский код
Обеспечивать единый интерфейс для работы с разнородными структурами данных
Реализовывать ленивую инициализацию и отложенную загрузку элементов
Поддерживать безопасное удаление элементов во время обхода
Архитектура интерфейса Iterator
Интерфейс Iterator<E> определен в пакете java.util и содержит три фундаментальных метода:
public interface Iterator<E> {
boolean hasNext();
E next();
void remove();
}Каждый из этих методов играет критически важную роль в процессе итерации и имеет свою собственную семантику и особенности реализации.
Метод hasNext(): Проверка наличия следующего элемента
Метод hasNext() выполняет предикативную функцию — определяет, существуют ли еще элементы для обхода в коллекции. Этот метод является безопасным и идемпотентным, что означает возможность его многократного вызова без побочных эффектов.
Семантика и поведение
Детерминированность: Метод всегда возвращает однозначный результат — true или false, без промежуточных состояний.
Отсутствие побочных эффектов: Вызов hasNext() не модифицирует состояние итератора и не перемещает указатель текущей позиции.
Инвариантность: Результат метода зависит исключительно от внутреннего состояния итератора и коллекции на момент вызова.
Внутренние механизмы реализации
Для коллекций с известным размером (ArrayList, HashSet)
В коллекциях, где количество элементов известно заранее или может быть быстро вычислено, реализация hasNext() обычно сводится к простому сравнению:
// Концептуальная реализация для ArrayList
public boolean hasNext() {
return currentPosition < size;
}
Оптимизации:
Кэширование размера коллекции для избежания повторных вычислений
Флаги для отслеживания структурных изменений коллекции
Минимальные проверки для максимизации производительности
Для ленивых или потоковых коллекций
В случаях, когда элементы генерируются на лету или загружаются отложенно, реализация hasNext() может быть более сложной:
Проверка наличия данных в буфере
Запрос к внешнему источнику данных
Ожидание генерации следующего элемента
Обработка возможных исключений
Для структур данных со сложной навигацией (TreeMap, LinkedList)
В итераторах для сложных структур реализация hasNext() требует анализа внутреннего состояния:
Проверка достижения листовых узлов в деревьях
Анализ ссылок в связных списках
Учет особенностей обхода для конкретного алгоритма (in-order, pre-order, post-order)
Особенности производительности
Временная сложность: В большинстве реализаций hasNext() выполняется за O(1) время, так как требует только проверки условий без обхода структур.
Потребление памяти: Метод не создает новых объектов и использует минимальное количество временных переменных.
Thread-safety: В стандартных реализациях hasNext() не является потокобезопасным методом. Concurrent модификации коллекции могут привести к неконсистентным результатам.
Паттерны использования
Классический цикл обхода
Iterator<String> iterator = collection.iterator();
while (iterator.hasNext()) {
String element = iterator.next();
// Обработка элемента
}
Защита от пустых коллекций
if (iterator.hasNext()) {
// Коллекция не пуста, можно начинать обработку
processFirstElement(iterator.next());
}#Java #для_новичков #beginner #Iterator
👍4
Предварительная проверка перед сложными операциями
Метод next(): Получение следующего элемента
Метод next() является основным двигателем итерации — он возвращает следующий элемент коллекции и продвигает внутренний указатель позиции. Этот метод сочетает в себе функциональность доступа к данным и изменения состояния итератора.
Семантика и поведение
Изменение состояния: Каждый успешный вызов next() модифицирует внутреннее состояние итератора, перемещая указатель текущей позиции.
Исключительные ситуации: Если элементов больше нет, метод выбрасывает NoSuchElementException.
Порядок обхода: Возвращает элементы в порядке, определенном конкретной реализацией итератора для данной коллекции.
Внутренние механизмы реализации
Для массивных структур (ArrayList, ArrayDeque)
Для коллекций на основе массивов реализация next() обычно прямолинейна:
Ключевые аспекты:
Сохранение индекса последнего возвращенного элемента для поддержки remove()
Постинкрементация указателя текущей позиции
Прямой доступ к массиву через индекс
Для связных структур (LinkedList, TreeSet)
В итераторах для связных структур реализация более сложна:
Особенности:
Навигация по ссылкам между узлами
Поддержка различных направлений обхода
Учет особенностей структуры (например, балансировки деревьев)
Для fail-fast итераторов
Многие реализации итераторов в Java используют механизм fail-fast, который включает дополнительную проверку:
Механизм проверки: Сравнение внутреннего счетчика модификаций итератора с счетчиком коллекции.
Обработка исключительных ситуаций
NoSuchElementException
Это исключение сигнализирует о попытке получить элемент за пределами коллекции. Оно является unchecked исключением и обычно указывает на логическую ошибку в коде.
Типичные причины:
Неправильное условие завершения цикла
Параллельные модификации коллекции
Ошибки в логике работы с итератором
ConcurrentModificationException
В fail-fast итераторах возникает при обнаружении структурных изменений коллекции во время итерации.
Стратегии предотвращения:
Использование synchronized коллекций
Применение копий коллекций для итерации
Использование специальных concurrent итераторов
Особенности производительности
Временная сложность: Зависит от структуры данных:
ArrayList: O(1)
LinkedList: O(1) для перехода между узлами (но O(n) для поиска начальной позиции)
TreeSet: O(1) amortized для сбалансированных деревьев
Память: Может создавать временные объекты или сохранять ссылки для поддержки операций удаления.
Потокобезопасность: Стандартные реализации не являются потокобезопасными.
Паттерны использования
Последовательная обработка всех элементов
Ограниченная обработка
Пропуск элементов
#Java #для_новичков #beginner #Iterator
while (iterator.hasNext()) {
if (shouldProcessNext()) {
processElement(iterator.next());
} else {
break; // Ранний выход из цикла
}
}Метод next(): Получение следующего элемента
Метод next() является основным двигателем итерации — он возвращает следующий элемент коллекции и продвигает внутренний указатель позиции. Этот метод сочетает в себе функциональность доступа к данным и изменения состояния итератора.
Семантика и поведение
Изменение состояния: Каждый успешный вызов next() модифицирует внутреннее состояние итератора, перемещая указатель текущей позиции.
Исключительные ситуации: Если элементов больше нет, метод выбрасывает NoSuchElementException.
Порядок обхода: Возвращает элементы в порядке, определенном конкретной реализацией итератора для данной коллекции.
Внутренние механизмы реализации
Для массивных структур (ArrayList, ArrayDeque)
Для коллекций на основе массивов реализация next() обычно прямолинейна:
// Концептуальная реализация для ArrayList
public E next() {
if (!hasNext()) {
throw new NoSuchElementException();
}
lastReturned = currentPosition;
return elementData[currentPosition++];
}
Ключевые аспекты:
Сохранение индекса последнего возвращенного элемента для поддержки remove()
Постинкрементация указателя текущей позиции
Прямой доступ к массиву через индекс
Для связных структур (LinkedList, TreeSet)
В итераторах для связных структур реализация более сложна:
// Концептуальная реализация для LinkedList
public E next() {
if (!hasNext()) {
throw new NoSuchElementException();
}
lastReturned = current;
current = current.next; // Переход к следующему узлу
return lastReturned.item;
}
Особенности:
Навигация по ссылкам между узлами
Поддержка различных направлений обхода
Учет особенностей структуры (например, балансировки деревьев)
Для fail-fast итераторов
Многие реализации итераторов в Java используют механизм fail-fast, который включает дополнительную проверку:
public E next() {
checkForComodification(); // Проверка структурных изменений
if (!hasNext()) {
throw new NoSuchElementException();
}
// ... основная логика
}Механизм проверки: Сравнение внутреннего счетчика модификаций итератора с счетчиком коллекции.
Обработка исключительных ситуаций
NoSuchElementException
Это исключение сигнализирует о попытке получить элемент за пределами коллекции. Оно является unchecked исключением и обычно указывает на логическую ошибку в коде.
Типичные причины:
Неправильное условие завершения цикла
Параллельные модификации коллекции
Ошибки в логике работы с итератором
ConcurrentModificationException
В fail-fast итераторах возникает при обнаружении структурных изменений коллекции во время итерации.
Стратегии предотвращения:
Использование synchronized коллекций
Применение копий коллекций для итерации
Использование специальных concurrent итераторов
Особенности производительности
Временная сложность: Зависит от структуры данных:
ArrayList: O(1)
LinkedList: O(1) для перехода между узлами (но O(n) для поиска начальной позиции)
TreeSet: O(1) amortized для сбалансированных деревьев
Память: Может создавать временные объекты или сохранять ссылки для поддержки операций удаления.
Потокобезопасность: Стандартные реализации не являются потокобезопасными.
Паттерны использования
Последовательная обработка всех элементов
while (iterator.hasNext()) {
Element element = iterator.next();
processElement(element);
}Ограниченная обработка
for (int i = 0; i < limit && iterator.hasNext(); i++) {
Element element = iterator.next();
processElement(element);
}Пропуск элементов
// Пропустить первые N элементов
for (int i = 0; i < skipCount && iterator.hasNext(); i++) {
iterator.next();
}
// Обработать оставшиеся
while (iterator.hasNext()) {
processElement(iterator.next());
}
#Java #для_новичков #beginner #Iterator
👍3
Метод remove(): Удаление текущего элемента
Метод remove() представляет собой одну из наиболее сложных и тонких операций в интерфейсе итератора. Он позволяет удалить из коллекции элемент, который был последним возвращен вызовом next(). Этот метод обеспечивает безопасное удаление во время итерации, что невозможно при использовании методов удаления самой коллекции.
Семантика и поведение
Состояние зависимости: Может быть вызван только после успешного вызова next() и только один раз для каждого вызова next().
Исключительные ситуации: Выбрасывает IllegalStateException при нарушении условий вызова.
Структурное изменение: Модифицирует как коллекцию, так и внутреннее состояние итератора.
Внутренние механизмы реализации
Общий алгоритм работы
Для ArrayList
Реализация remove() в ArrayListIterator требует особой обработки из-за массива как базовой структуры:
Специфические аспекты:
Сдвиг элементов массива после удаления
Корректировка текущей позиции итератора
Обновление счетчиков модификаций
Для LinkedList
В LinkedListIterator реализация использует преимущества связной структуры:
Преимущества связной структуры:
Более эффективное удаление (O(1) после нахождения узла)
Простая корректировка ссылок
Естественная поддержка удаления во время итерации
Условия корректного вызова
Необходимые предварительные условия
Предшествующий успешный вызов next(): Должен быть получен элемент для удаления
Отсутствие промежуточных вызовов remove(): Для каждого next() может быть только один remove()
Совместимость состояния: Итератор и коллекция должны быть синхронизированы
Типичные ошибки и исключения
IllegalStateException:
Вызов remove() до первого вызова next()
Повторный вызов remove() для того же элемента
Вызов remove() после структурных изменений коллекции другими средствами
ConcurrentModificationException:
Параллельные модификации коллекции из других потоков
Использование методов удаления самой коллекции во время итерации
Особенности производительности
Временная сложность: Зависит от базовой коллекции:
ArrayList: O(n) из-за необходимости сдвига элементов
LinkedList: O(1) после нахождения узла
HashSet: O(1) в среднем случае
Потокобезопасность: Стандартные реализации не являются потокобезопасными.
Побочные эффекты: Изменяет размер коллекции и инвалидирует некоторые операции.
#Java #для_новичков #beginner #Iterator
Метод remove() представляет собой одну из наиболее сложных и тонких операций в интерфейсе итератора. Он позволяет удалить из коллекции элемент, который был последним возвращен вызовом next(). Этот метод обеспечивает безопасное удаление во время итерации, что невозможно при использовании методов удаления самой коллекции.
Семантика и поведение
Состояние зависимости: Может быть вызван только после успешного вызова next() и только один раз для каждого вызова next().
Исключительные ситуации: Выбрасывает IllegalStateException при нарушении условий вызова.
Структурное изменение: Модифицирует как коллекцию, так и внутреннее состояние итератора.
Внутренние механизмы реализации
Общий алгоритм работы
// Концептуальный шаблон реализации
public void remove() {
if (lastReturned == null) {
throw new IllegalStateException();
}
checkForComodification();
// Удаление элемента из коллекции
collection.removeElement(lastReturned);
// Корректировка состояния итератора
adjustIteratorState();
lastReturned = null;
expectedModCount = modCount;
}
Для ArrayList
Реализация remove() в ArrayListIterator требует особой обработки из-за массива как базовой структуры:
public void remove() {
if (lastReturned < 0) {
throw new IllegalStateException();
}
checkForComodification();
try {
// Удаление элемента из ArrayList
ArrayList.this.remove(lastReturned);
// Корректировка позиции итератора
cursor = lastReturned;
lastReturned = -1;
expectedModCount = modCount;
} catch (IndexOutOfBoundsException ex) {
throw new ConcurrentModificationException();
}
}Специфические аспекты:
Сдвиг элементов массива после удаления
Корректировка текущей позиции итератора
Обновление счетчиков модификаций
Для LinkedList
В LinkedListIterator реализация использует преимущества связной структуры:
public void remove() {
checkForComodification();
if (lastReturned == null) {
throw new IllegalStateException();
}
Node<E> lastNext = lastReturned.next;
// Удаление узла из связного списка
unlink(lastReturned);
if (next == lastReturned) {
next = lastNext;
} else {
nextIndex--;
}
lastReturned = null;
expectedModCount++;
}Преимущества связной структуры:
Более эффективное удаление (O(1) после нахождения узла)
Простая корректировка ссылок
Естественная поддержка удаления во время итерации
Условия корректного вызова
Необходимые предварительные условия
Предшествующий успешный вызов next(): Должен быть получен элемент для удаления
Отсутствие промежуточных вызовов remove(): Для каждого next() может быть только один remove()
Совместимость состояния: Итератор и коллекция должны быть синхронизированы
Типичные ошибки и исключения
IllegalStateException:
Вызов remove() до первого вызова next()
Повторный вызов remove() для того же элемента
Вызов remove() после структурных изменений коллекции другими средствами
ConcurrentModificationException:
Параллельные модификации коллекции из других потоков
Использование методов удаления самой коллекции во время итерации
Особенности производительности
Временная сложность: Зависит от базовой коллекции:
ArrayList: O(n) из-за необходимости сдвига элементов
LinkedList: O(1) после нахождения узла
HashSet: O(1) в среднем случае
Потокобезопасность: Стандартные реализации не являются потокобезопасными.
Побочные эффекты: Изменяет размер коллекции и инвалидирует некоторые операции.
#Java #для_новичков #beginner #Iterator
👍2
Паттерны использования
Безопасное удаление во время итерации
Фильтрация коллекции
Очистка коллекции по условию
Сравнение с альтернативными подходами
Iterator.remove() vs Collection.remove()
Преимущества Iterator.remove():
Безопасность во время итерации
Корректное обновление состояния итератора
Оптимизированная реализация для конкретной структуры данных
Недостатки Collection.remove():
Риск ConcurrentModificationException
Необходимость повторного поиска элемента
Потенциальная неэффективность
Iterator.remove() vs Copy-and-Filter
Копирование с фильтрацией:
Сравнение:
Копирование: Проще, но требует дополнительной памяти
Итератор: Эффективнее по памяти, но требует осторожности
Интеграция трех методов: Полный цикл итерации
Согласованная работа hasNext(), next() и remove()
Эти три метода образуют единую систему, где каждый играет свою роль в процессе итерации:
#Java #для_новичков #beginner #Iterator
Безопасное удаление во время итерации
Iterator<Item> iterator = collection.iterator();
while (iterator.hasNext()) {
Item item = iterator.next();
if (shouldRemove(item)) {
iterator.remove(); // Безопасное удаление
}
}
Фильтрация коллекции
public static <T> void filter(Collection<T> collection, Predicate<T> predicate) {
Iterator<T> iterator = collection.iterator();
while (iterator.hasNext()) {
if (!predicate.test(iterator.next())) {
iterator.remove();
}
}
}Очистка коллекции по условию
// Удалить все null элементы
iterator = list.iterator();
while (iterator.hasNext()) {
if (iterator.next() == null) {
iterator.remove();
}
}
Сравнение с альтернативными подходами
Iterator.remove() vs Collection.remove()
Преимущества Iterator.remove():
Безопасность во время итерации
Корректное обновление состояния итератора
Оптимизированная реализация для конкретной структуры данных
Недостатки Collection.remove():
Риск ConcurrentModificationException
Необходимость повторного поиска элемента
Потенциальная неэффективность
Iterator.remove() vs Copy-and-Filter
Копирование с фильтрацией:
List<Item> filtered = new ArrayList<>();
for (Item item : original) {
if (!shouldRemove(item)) {
filtered.add(item);
}
}
original = filtered;
Сравнение:
Копирование: Проще, но требует дополнительной памяти
Итератор: Эффективнее по памяти, но требует осторожности
Интеграция трех методов: Полный цикл итерации
Согласованная работа hasNext(), next() и remove()
Эти три метода образуют единую систему, где каждый играет свою роль в процессе итерации:
public class SafeIterationExample {
public static void processAndRemove(Collection<Data> collection) {
Iterator<Data> iterator = collection.iterator();
// Фаза 1: Подготовка и проверка
while (iterator.hasNext()) {
// Фаза 2: Получение элемента
Data data = iterator.next();
// Фаза 3: Обработка и возможное удаление
if (data.isProcessed()) {
iterator.remove(); // Безопасное удаление
} else {
data.process();
}
}
}
}#Java #для_новичков #beginner #Iterator
👍2
Паттерны управления состоянием
Управление состоянием lastReturned
Правильное управление полем lastReturned критически важно для корректной работы remove():
Установка: В next() после успешного получения элемента
Сброс: В remove() после успешного удаления
Проверка: Перед вызовом remove() для валидации состояния
Синхронизация счетчиков модификаций
Для fail-fast итераторов необходимо поддерживать синхронизацию:
expectedModCount: Сохраняется при создании итератора
modCount: Обновляется при структурных изменениях коллекции
Сравнение: При каждой операции проверяется равенство счетчиков
Расширенные сценарии использования
Итерация с пропуском элементов
Пакетная обработка с удалением
Best Practices и рекомендации
Эффективное использование итераторов
Используйте enhanced for-loop когда возможно:
Избегайте ненужных вызовов hasNext():
Безопасность в многопоточных сценариях
Синхронизируйте доступ к итераторам:
Используйте потокобезопасные альтернативы:
Избегайте структурных изменений во время итерации:
#Java #для_новичков #beginner #Iterator
Управление состоянием lastReturned
Правильное управление полем lastReturned критически важно для корректной работы remove():
Установка: В next() после успешного получения элемента
Сброс: В remove() после успешного удаления
Проверка: Перед вызовом remove() для валидации состояния
Синхронизация счетчиков модификаций
Для fail-fast итераторов необходимо поддерживать синхронизацию:
expectedModCount: Сохраняется при создании итератора
modCount: Обновляется при структурных изменениях коллекции
Сравнение: При каждой операции проверяется равенство счетчиков
Расширенные сценарии использования
Итерация с пропуском элементов
public static <T> void skipAndProcess(Iterator<T> iterator, int skipCount) {
// Пропуск первых N элементов
for (int i = 0; i < skipCount && iterator.hasNext(); i++) {
iterator.next();
}
// Обработка оставшихся с возможным удалением
while (iterator.hasNext()) {
T element = iterator.next();
if (shouldProcess(element)) {
processElement(element);
} else {
iterator.remove();
}
}
}Пакетная обработка с удалением
public static <T> List<T> batchProcessAndRemove(
Collection<T> collection,
Predicate<T> removalCondition,
int batchSize) {
List<T> removed = new ArrayList<>();
Iterator<T> iterator = collection.iterator();
int processed = 0;
while (iterator.hasNext() && processed < batchSize) {
T element = iterator.next();
if (removalCondition.test(element)) {
removed.add(element);
iterator.remove();
}
processed++;
}
return removed;
}
Best Practices и рекомендации
Эффективное использование итераторов
Используйте enhanced for-loop когда возможно:
for (Element element : collection) {
// Автоматическое управление итератором
}Избегайте ненужных вызовов hasNext():
// Неоптимально:
while (iterator.hasNext()) {
if (condition) {
process(iterator.next());
}
}
// Оптимально:
while (iterator.hasNext()) {
Element element = iterator.next();
if (condition) {
process(element);
}
}
Безопасность в многопоточных сценариях
Синхронизируйте доступ к итераторам:
synchronized(collection) {
Iterator<E> iterator = collection.iterator();
while (iterator.hasNext()) {
// Обработка
}
}Используйте потокобезопасные альтернативы:
// CopyOnWriteArrayList для read-heavy workloads
// ConcurrentHashMap для concurrent модификаций
// Collections.synchronized для оберток
Избегайте структурных изменений во время итерации:
// Собирайте элементы для удаления отдельно
List<Element> toRemove = new ArrayList<>();
for (Element element : collection) {
if (shouldRemove(element)) {
toRemove.add(element);
}
}
collection.removeAll(toRemove);
#Java #для_новичков #beginner #Iterator
👍2
Predicates (условия маршрутизации)
Predicates в Spring Cloud Gateway — это функции, которые принимают ServerWebExchange и возвращают boolean, определяя, попадает ли входящий запрос под конкретный Route. Predicates — фундамент маршрутизации: маршрут считается подходящим только если все его предикаты возвращают true (логическое AND между перечисленными предикатами одного маршрута). Понимание механизмов работы предикатов критично для корректного и производительного построения маршрутов.
Ключевые принципы — механика и порядок
Маршрут выбран, если все его предикаты истинны.
В конфигурации YAML или Java DSL, когда у Route указано несколько предикатов, они объединяются логически через AND.
Порядок маршрутов важен.
Gateway перебирает доступные маршруты в порядке, определённом компонентом, который предоставляет Flux<Route> (обычно RouteDefinitionLocator → RouteDefinitionRouteLocator). Конкретный порядок определяется полем order (если задано) или порядком получения/создания маршрутов. Первый подходящий маршрут (в смысле совпадения предикатов) берётся в обработку. Следовательно, дешёвые «фильтрующие» предикаты (например, Host, Method) следует располагать раньше в конфигурации маршрутов по логике — не путать с порядком предикатов в одном маршруте: в одном маршруте порядок предикатов обычно не меняет семантику, но влияет на порядок выполнения (см. рекомендации по эффективности ниже).
Оценка предикатов — последовательная и краткая:
Для одного маршрута предикаты обычно вычисляются последовательно и, при первом false, дальнейшая проверка предикатов для этого маршрута останавливается (short-circuit). Тем не менее, поскольку маршрутов может быть много, Gateway продолжит проверять следующие маршруты до нахождения первого подходящего.
Рекомендации по производительности:
Помещайте дешёвые и часто отсекающие проверки (например, Host, Method, Path) до дорогих вычислений (например, проверки содержимого тела, обращения в внешние сервисы или сложных регулярных выражений).
Избегайте предикатов, которые делают блокирующие операции — predicated должны быть чисто вычислительными и быстрыми. При необходимости используйте Java DSL и инкапсулируйте асинхронную работу в фильтрах, а не в предикатах.
Если нужна сложная проверка, лучше вынести её в отдельный, оптимизированный RoutePredicateFactory (см. ниже).
Композиция логики (AND/OR):
AND — поведение по умолчанию: несколько предикатов в одном Route объединяются через AND.
OR — декларативно не представлен как оператор на уровне одной записи YAML; для выражения OR чаще используют либо несколько маршрутов с разными наборами предикатов, либо пишут кастомный предикат, который внутри реализует логическое OR. В Java DSL также проще объявить несколько маршрутов или написать композиционный предикат в коде.
Встроенные предикаты — семантика, YAML-примеры, Java DSL-примеры
Ниже даны наиболее часто используемые предикаты, их поведение и примеры конфигурации.
1) Path
Проверяет соответствие URL-пути. Поддерживает шаблоны в стиле Ant (/users/**, /api/*/items) и также поддерживает регулярные группы при использовании Rewrite и фильтров.
YAML:
Java DSL:
Замечание: Path — обычно самый дешёвый и самый часто используемый предикат; ставьте его в начале списка логических проверок маршрутов.
2) Host
Проверяет заголовок Host (например, api.example.com). Поддерживает подстановки (*.example.com).
YAML:
Java DSL:
Заметка: Host — особенно полезен при мульти-тенантной конфигурации.
#Java #middle #Spring_Cloud_Gateway
Predicates в Spring Cloud Gateway — это функции, которые принимают ServerWebExchange и возвращают boolean, определяя, попадает ли входящий запрос под конкретный Route. Predicates — фундамент маршрутизации: маршрут считается подходящим только если все его предикаты возвращают true (логическое AND между перечисленными предикатами одного маршрута). Понимание механизмов работы предикатов критично для корректного и производительного построения маршрутов.
Ключевые принципы — механика и порядок
Маршрут выбран, если все его предикаты истинны.
В конфигурации YAML или Java DSL, когда у Route указано несколько предикатов, они объединяются логически через AND.
Порядок маршрутов важен.
Gateway перебирает доступные маршруты в порядке, определённом компонентом, который предоставляет Flux<Route> (обычно RouteDefinitionLocator → RouteDefinitionRouteLocator). Конкретный порядок определяется полем order (если задано) или порядком получения/создания маршрутов. Первый подходящий маршрут (в смысле совпадения предикатов) берётся в обработку. Следовательно, дешёвые «фильтрующие» предикаты (например, Host, Method) следует располагать раньше в конфигурации маршрутов по логике — не путать с порядком предикатов в одном маршруте: в одном маршруте порядок предикатов обычно не меняет семантику, но влияет на порядок выполнения (см. рекомендации по эффективности ниже).
Оценка предикатов — последовательная и краткая:
Для одного маршрута предикаты обычно вычисляются последовательно и, при первом false, дальнейшая проверка предикатов для этого маршрута останавливается (short-circuit). Тем не менее, поскольку маршрутов может быть много, Gateway продолжит проверять следующие маршруты до нахождения первого подходящего.
Рекомендации по производительности:
Помещайте дешёвые и часто отсекающие проверки (например, Host, Method, Path) до дорогих вычислений (например, проверки содержимого тела, обращения в внешние сервисы или сложных регулярных выражений).
Избегайте предикатов, которые делают блокирующие операции — predicated должны быть чисто вычислительными и быстрыми. При необходимости используйте Java DSL и инкапсулируйте асинхронную работу в фильтрах, а не в предикатах.
Если нужна сложная проверка, лучше вынести её в отдельный, оптимизированный RoutePredicateFactory (см. ниже).
Композиция логики (AND/OR):
AND — поведение по умолчанию: несколько предикатов в одном Route объединяются через AND.
OR — декларативно не представлен как оператор на уровне одной записи YAML; для выражения OR чаще используют либо несколько маршрутов с разными наборами предикатов, либо пишут кастомный предикат, который внутри реализует логическое OR. В Java DSL также проще объявить несколько маршрутов или написать композиционный предикат в коде.
Встроенные предикаты — семантика, YAML-примеры, Java DSL-примеры
Ниже даны наиболее часто используемые предикаты, их поведение и примеры конфигурации.
1) Path
Проверяет соответствие URL-пути. Поддерживает шаблоны в стиле Ant (/users/**, /api/*/items) и также поддерживает регулярные группы при использовании Rewrite и фильтров.
YAML:
predicates:
- Path=/api/users/**
Java DSL:
.route("users", r -> r.path("/api/users/**")
.uri("lb://user-service"))Замечание: Path — обычно самый дешёвый и самый часто используемый предикат; ставьте его в начале списка логических проверок маршрутов.
2) Host
Проверяет заголовок Host (например, api.example.com). Поддерживает подстановки (*.example.com).
YAML:
predicates:
- Host=api.example.com, *.internal.example.org
Java DSL:
.route("host-route", r -> r.host("api.example.com", "*.internal.example.org")
.uri("http://localhost:8080"))Заметка: Host — особенно полезен при мульти-тенантной конфигурации.
#Java #middle #Spring_Cloud_Gateway
👍2
3) Method
Сравнивает HTTP-метод (GET/POST/PUT/...).
YAML:
Java DSL:
4) Header
Проверяет наличие и (при задании) значение заголовка. Поддерживает регулярные выражения на значение.
YAML:
Java DSL:
Если значение не указано — проверяется только наличие заголовка.
5) Query
Проверяет наличие параметра query и, при наличии второго аргумента, — значение (регулярное выражение).
YAML:
Java DSL:
6) RemoteAddr
Проверяет IP-адрес клиента — поддерживает одиночные адреса и CIDR. Важно: в случае проксирования через балансировщики/Gateway заранее убедитесь, какие IP попадают в RemoteAddr (реальный клиент или IP reverse-proxy). Иногда требуется проверка X-Forwarded-For.
YAML:
Java DSL:
7) Weight / Load Balancer predicates (логика распределения) — концепция и применение
Weight — предикат, встречающийся в экосистеме Spring Cloud Gateway в контексте динамических маршрутов и Discovery клиента. Его цель — поддержка взвешенной маршрутизации: когда один и тот же serviceId представлен несколькими маршрутами с разными весами (weight), Gateway на этапе выбора маршрута учитывает веса (для канареечных релизов, A/B, geo-aware routing и т.п.).
Практическая схема использования:
Discovery-driven маршрутизация (DiscoveryClientRouteDefinitionLocator) может генерировать маршруты для каждого экземпляра/группы с метаданными веса.
Weight-предикат в составе маршрута проверяет — подходит ли текущий запрос под данный «весовой» маршрут (обычно реализуется через случайное/round-robin решение, зависящее от weight).
Примечание по реализации и совместимости: синтаксис и встроенные реализации могут различаться между версиями Spring Cloud.
Если требуется взвешенная маршрутизация в production, часто применяют:
Spring Cloud LoadBalancer для распределения трафика по инстансам;
Weight-подход в комбинировании с DiscoveryClientRouteDefinitionLocator или кастомным RouteDefinitionRepository.
Если нужен пример конфигурации — лучше реализовать weight механизмы через Discovery + metadata на стороне сервисов или через кастомный RoutePredicateFactory (пример ниже покажет, как писать свой предикат).
Сложные комбинации — AND / OR / NOT
AND: стандартная комбинация — несколько предикатов в одном Route → все должны быть true. Шаблон конфигурирования одинаков как в YAML, так и в DSL.
OR: декларативного OR в одном Route нет.
Для выражения OR есть два варианта:
Несколько маршрутов: создайте два (или больше) маршрута, каждый с различным предикатом; порядок важен, если маршруты пересекаются.
Кастомный предикат (composite): напишите RoutePredicateFactory, который внутри реализует логику a || b, и используйте его как обычный предикат. Это предпочтительно, если хотите избежать дублирования конфигурации и централизовать логику.
NOT / Negation: также не представлен в YAML как отдельный оператор; реализуется кастомным предикатом или путём композиции (например, создание предиката NotHeader).
#Java #middle #Spring_Cloud_Gateway
Сравнивает HTTP-метод (GET/POST/PUT/...).
YAML:
predicates:
- Method=GET,POST
Java DSL:
.route("read-write", r -> r.method(HttpMethod.GET, HttpMethod.POST)
.uri("lb://some-service"))4) Header
Проверяет наличие и (при задании) значение заголовка. Поддерживает регулярные выражения на значение.
YAML:
predicates:
- Header=X-Client, ^mobile-.*
Java DSL:
.route("header-route", r -> r.header("X-Client", "^mobile-.*")
.uri("http://mobile-backend"))Если значение не указано — проверяется только наличие заголовка.
5) Query
Проверяет наличие параметра query и, при наличии второго аргумента, — значение (регулярное выражение).
YAML:
predicates:
- Query=version, ^v[0-9]+$
Java DSL:
.route("versioned", r -> r.query("version", "^v[0-9]+$")
.uri("lb://versioned-service"))6) RemoteAddr
Проверяет IP-адрес клиента — поддерживает одиночные адреса и CIDR. Важно: в случае проксирования через балансировщики/Gateway заранее убедитесь, какие IP попадают в RemoteAddr (реальный клиент или IP reverse-proxy). Иногда требуется проверка X-Forwarded-For.
YAML:
predicates:
- RemoteAddr=192.168.1.0/24, 10.0.0.10
Java DSL:
.route("internal-only", r -> r.remoteAddr("192.168.0.0/16", "10.0.0.0/8")
.uri("lb://internal-service"))7) Weight / Load Balancer predicates (логика распределения) — концепция и применение
Weight — предикат, встречающийся в экосистеме Spring Cloud Gateway в контексте динамических маршрутов и Discovery клиента. Его цель — поддержка взвешенной маршрутизации: когда один и тот же serviceId представлен несколькими маршрутами с разными весами (weight), Gateway на этапе выбора маршрута учитывает веса (для канареечных релизов, A/B, geo-aware routing и т.п.).
Практическая схема использования:
Discovery-driven маршрутизация (DiscoveryClientRouteDefinitionLocator) может генерировать маршруты для каждого экземпляра/группы с метаданными веса.
Weight-предикат в составе маршрута проверяет — подходит ли текущий запрос под данный «весовой» маршрут (обычно реализуется через случайное/round-robin решение, зависящее от weight).
Примечание по реализации и совместимости: синтаксис и встроенные реализации могут различаться между версиями Spring Cloud.
Если требуется взвешенная маршрутизация в production, часто применяют:
Spring Cloud LoadBalancer для распределения трафика по инстансам;
Weight-подход в комбинировании с DiscoveryClientRouteDefinitionLocator или кастомным RouteDefinitionRepository.
Если нужен пример конфигурации — лучше реализовать weight механизмы через Discovery + metadata на стороне сервисов или через кастомный RoutePredicateFactory (пример ниже покажет, как писать свой предикат).
Сложные комбинации — AND / OR / NOT
AND: стандартная комбинация — несколько предикатов в одном Route → все должны быть true. Шаблон конфигурирования одинаков как в YAML, так и в DSL.
OR: декларативного OR в одном Route нет.
Для выражения OR есть два варианта:
Несколько маршрутов: создайте два (или больше) маршрута, каждый с различным предикатом; порядок важен, если маршруты пересекаются.
Кастомный предикат (composite): напишите RoutePredicateFactory, который внутри реализует логику a || b, и используйте его как обычный предикат. Это предпочтительно, если хотите избежать дублирования конфигурации и централизовать логику.
NOT / Negation: также не представлен в YAML как отдельный оператор; реализуется кастомным предикатом или путём композиции (например, создание предиката NotHeader).
#Java #middle #Spring_Cloud_Gateway
👍2
Написание собственного Predicate — RoutePredicateFactory
Когда встроенных предикатов недостаточно по логике или производительности, пишут собственные RoutePredicateFactory. Ниже — полный пример: реализуем предикат, который проверяет наличие параметра X-Feature и сопоставляет его по списку допустимых значений, при этом конфигурируемый через YAML.
1) Структура — класс предиката
Ключевые моменты:
Наследуемся от AbstractRoutePredicateFactory<Config>. Это даёт поддержку автоконфигурируемой десериализации конфигурации из YAML в Config.
apply(Config) возвращает Predicate<ServerWebExchange>, который будет выполняться для каждого запроса.
Config — POJO с геттерами/сеттерами: Spring автоматически маппит значения из YAML (через Binder).
2) Регистрация (component или bean)
Если не использовать @Component, можно зарегистрировать как bean через конфигурацию.
3) Использование в YAML
В AbstractRoutePredicateFactory стандартная разбивка аргументов (если конфиг простой) позволит подставить список значений. Для более сложной настройки (ключ:значение) необходимо переопределить shortcutFieldOrder() или использовать вложенный Config с именованными полями.
4) Использование в Java DSL
Если хотите inline-предикат в коде (без фабрики), Java DSL позволяет:
Однако такой inline-предикат теряет преимущества конфигурируемости через YAML и переиспользуемости.
#Java #middle #Spring_Cloud_Gateway
Когда встроенных предикатов недостаточно по логике или производительности, пишут собственные RoutePredicateFactory. Ниже — полный пример: реализуем предикат, который проверяет наличие параметра X-Feature и сопоставляет его по списку допустимых значений, при этом конфигурируемый через YAML.
1) Структура — класс предиката
import org.springframework.cloud.gateway.handler.predicate.AbstractRoutePredicateFactory;
import org.springframework.web.server.ServerWebExchange;
import java.util.function.Predicate;
import java.util.List;
public class XFeatureRoutePredicateFactory extends AbstractRoutePredicateFactory<XFeatureRoutePredicateFactory.Config> {
public XFeatureRoutePredicateFactory() {
super(Config.class);
}
@Override
public Predicate<ServerWebExchange> apply(Config config) {
List<String> allowed = config.getAllowedValues();
boolean ignoreCase = config.isIgnoreCase();
return exchange -> {
List<String> headerValues = exchange.getRequest().getHeaders().get("X-Feature");
if (headerValues == null || headerValues.isEmpty()) {
return false;
}
for (String hv : headerValues) {
for (String allowedVal : allowed) {
if (ignoreCase) {
if (hv.equalsIgnoreCase(allowedVal)) return true;
} else {
if (hv.equals(allowedVal)) return true;
}
}
}
return false;
};
}
public static class Config {
private List<String> allowedValues;
private boolean ignoreCase = true;
public List<String> getAllowedValues() { return allowedValues; }
public void setAllowedValues(List<String> allowedValues) { this.allowedValues = allowedValues; }
public boolean isIgnoreCase() { return ignoreCase; }
public void setIgnoreCase(boolean ignoreCase) { this.ignoreCase = ignoreCase; }
}
}
Ключевые моменты:
Наследуемся от AbstractRoutePredicateFactory<Config>. Это даёт поддержку автоконфигурируемой десериализации конфигурации из YAML в Config.
apply(Config) возвращает Predicate<ServerWebExchange>, который будет выполняться для каждого запроса.
Config — POJO с геттерами/сеттерами: Spring автоматически маппит значения из YAML (через Binder).
2) Регистрация (component или bean)
import org.springframework.stereotype.Component;
@Component
public class XFeatureRoutePredicateFactory extends AbstractRoutePredicateFactory<XFeatureRoutePredicateFactory.Config> {
// ... код как выше
}
Если не использовать @Component, можно зарегистрировать как bean через конфигурацию.
3) Использование в YAML
spring:
cloud:
gateway:
routes:
- id: feature-route
uri: http://feature-service
predicates:
- XFeature=allowed1,allowed2
В AbstractRoutePredicateFactory стандартная разбивка аргументов (если конфиг простой) позволит подставить список значений. Для более сложной настройки (ключ:значение) необходимо переопределить shortcutFieldOrder() или использовать вложенный Config с именованными полями.
4) Использование в Java DSL
Если хотите inline-предикат в коде (без фабрики), Java DSL позволяет:
.route("xfeature-inline", r -> r.p(exchange -> {
List<String> values = exchange.getRequest().getHeaders().get("X-Feature");
return values != null && values.stream().anyMatch(v -> v.equalsIgnoreCase("allowed1"));
}).uri("http://feature-service"))Однако такой inline-предикат теряет преимущества конфигурируемости через YAML и переиспользуемости.
#Java #middle #Spring_Cloud_Gateway
👍2
Работа с конфигурационными объектами и AbstractRoutePredicateFactory — тонкости
Shortcut configuration vs. full Config binding
Если RoutePredicateFactory использует короткий синтаксис (например: MyPred=val1,val2), то AbstractRoutePredicateFactory поддерживает маппинг по shortcutFieldOrder() — список полей Config, которые будут заполнены по порядку.
Для явной структуры лучше использовать именованные свойства в YAML и обычный биндинг в Config.
Валидация конфигурации
Валидируйте конфиг в конструкторе предиката или в apply() — например, проверить, что список не пуст. Ошибки конфигурации лучше бросать на старте приложения, а не при первом запросе.
Сериализация/десериализация сложных типов
Для сложных типов (например, Duration, Pattern, InetAddress[]) используйте соответствующие конвертеры или храните строковые представления и парсите в Config.
Потокобезопасность
Predicate возвращаемый apply() должен быть потокобезопасным и не содержать mutable state, зависящего от запроса; храните precomputed структуры (например Pattern), а не парсьте каждый раз.
Логирование и мониторинг
Для сложных предикатов логируйте причины отказа (на низком уровне) либо метрики отказов, чтобы упростить отладку некорректного маршрутизации.
Примеры: несколько реальных сценариев и лучшие практики
Пример 1 — комбинация Host + Path + Method (YAML)
Пример 2 — OR-логика через два маршрута (YAML)
Пример 3 — кастомный предикат с конфигом в YAML
#Java #middle #Spring_Cloud_Gateway
Shortcut configuration vs. full Config binding
Если RoutePredicateFactory использует короткий синтаксис (например: MyPred=val1,val2), то AbstractRoutePredicateFactory поддерживает маппинг по shortcutFieldOrder() — список полей Config, которые будут заполнены по порядку.
Для явной структуры лучше использовать именованные свойства в YAML и обычный биндинг в Config.
Валидация конфигурации
Валидируйте конфиг в конструкторе предиката или в apply() — например, проверить, что список не пуст. Ошибки конфигурации лучше бросать на старте приложения, а не при первом запросе.
Сериализация/десериализация сложных типов
Для сложных типов (например, Duration, Pattern, InetAddress[]) используйте соответствующие конвертеры или храните строковые представления и парсите в Config.
Потокобезопасность
Predicate возвращаемый apply() должен быть потокобезопасным и не содержать mutable state, зависящего от запроса; храните precomputed структуры (например Pattern), а не парсьте каждый раз.
Логирование и мониторинг
Для сложных предикатов логируйте причины отказа (на низком уровне) либо метрики отказов, чтобы упростить отладку некорректного маршрутизации.
Примеры: несколько реальных сценариев и лучшие практики
Пример 1 — комбинация Host + Path + Method (YAML)
routes:
- id: users-route
uri: lb://user-service
predicates:
- Host=api.example.com
- Path=/users/**
- Method=GET
Пояснение: типичный маршрут, дешёвые проверки (Host/Method/Path) — быстрый short-circuit.
Пример 2 — OR-логика через два маршрута (YAML)
routes:
- id: mobile-route
uri: lb://mobile-backend
predicates:
- Header=X-Client, ^mobile-.*
- Path=/api/**
- id: fallback-route
uri: lb://web-backend
predicates:
- Path=/api/**
Пояснение: первый маршрут отведёт мобильный трафик на mobile-backend; второй поймает остальные запросы по тому же Path — это простой способ построить OR-поведение без кастомных предикатов.
Пример 3 — кастомный предикат с конфигом в YAML
predicates:
- XFeature=allowedA,allowedB
(см. реализацию XFeatureRoutePredicateFactory выше).
#Java #middle #Spring_Cloud_Gateway
👍2
Глава 6. Итераторы
Интерфейс ListIterator — двунаправленный обход и расширенные возможности
ListIterator представляет собой специализированную версию интерфейса Iterator, разработанную исключительно для работы с реализациями интерфейса List. Этот расширенный интерфейс добавляет двунаправленный обход, модификацию элементов во время итерации и получение информации о текущей позиции. В отличие от базового Iterator, который предоставляет только однонаправленный обход и ограниченные возможности модификации, ListIterator превращает итерацию в полноценный механизм навигации по спискам.
ListIterator воплощает идею о том, что обход списка — это не просто последовательное чтение элементов, а полноценная навигация по структуре данных с возможностью движения в обоих направлениях, модификации элементов в любой точке и получения контекстной информации о текущей позиции. Этот подход особенно ценен для алгоритмов, требующих анализа соседних элементов или выполнения локальных модификаций без полного перебора коллекции.
Архитектура интерфейса ListIterator
ListIterator наследует от Iterator и добавляет значительное количество новых методов:
Каждый из этих методов расширяет функциональность итератора, превращая его в мощный инструмент для работы с упорядоченными коллекциями.
Фундаментальные методы двунаправленного обхода
hasPrevious() и previous(): Обратное движение
Концептуальное назначение
Методы hasPrevious() и previous() представляют собой зеркальное отражение hasNext() и next(), позволяющее двигаться по списку в обратном направлении. Эта пара методов реализует концепцию двунаправленного обхода, что является ключевым отличием ListIterator от базового Iterator.
Семантика и поведение
hasPrevious():
Возвращает true, если при движении в обратном направлении существуют элементы
Не изменяет состояние итератора
Может возвращать false в начальной позиции или после reset итератора
previous():
Возвращает предыдущий элемент и перемещает курсор назад
Выбрасывает NoSuchElementException, если предыдущих элементов нет
Устанавливает состояние для последующего вызова remove() или set()
Внутренние механизмы реализации
Позиционирование курсора
Ключевая концепция ListIterator — курсор, который находится между элементами списка.
Для списка из n элементов существует n+1 возможных позиций курсора:
Семантика операций:
next() возвращает элемент после курсора и перемещает курсор вперед
previous() возвращает элемент перед курсором и перемещает курсор назад
remove() удаляет последний возвращенный элемент
set(E e) заменяет последний возвращенный элемент
Реализация для ArrayList
Особенности:
Использование индекса вместо ссылок на узлы
Проверка границ массива
Обновление lastReturned для поддержки remove() и set()
Реализация для LinkedList
Особенности:
Навигация по ссылкам prev
Обработка граничных условий (первый/последний элемент)
Корректировка next и nextIndex
#Java #для_новичков #beginner #ListIterator
Интерфейс ListIterator — двунаправленный обход и расширенные возможности
ListIterator представляет собой специализированную версию интерфейса Iterator, разработанную исключительно для работы с реализациями интерфейса List. Этот расширенный интерфейс добавляет двунаправленный обход, модификацию элементов во время итерации и получение информации о текущей позиции. В отличие от базового Iterator, который предоставляет только однонаправленный обход и ограниченные возможности модификации, ListIterator превращает итерацию в полноценный механизм навигации по спискам.
ListIterator воплощает идею о том, что обход списка — это не просто последовательное чтение элементов, а полноценная навигация по структуре данных с возможностью движения в обоих направлениях, модификации элементов в любой точке и получения контекстной информации о текущей позиции. Этот подход особенно ценен для алгоритмов, требующих анализа соседних элементов или выполнения локальных модификаций без полного перебора коллекции.
Архитектура интерфейса ListIterator
ListIterator наследует от Iterator и добавляет значительное количество новых методов:
public interface ListIterator<E> extends Iterator<E> {
// Наследуемые методы
boolean hasNext();
E next();
void remove();
// Новые методы
boolean hasPrevious();
E previous();
int nextIndex();
int previousIndex();
void set(E e);
void add(E e);
}Каждый из этих методов расширяет функциональность итератора, превращая его в мощный инструмент для работы с упорядоченными коллекциями.
Фундаментальные методы двунаправленного обхода
hasPrevious() и previous(): Обратное движение
Концептуальное назначение
Методы hasPrevious() и previous() представляют собой зеркальное отражение hasNext() и next(), позволяющее двигаться по списку в обратном направлении. Эта пара методов реализует концепцию двунаправленного обхода, что является ключевым отличием ListIterator от базового Iterator.
Семантика и поведение
hasPrevious():
Возвращает true, если при движении в обратном направлении существуют элементы
Не изменяет состояние итератора
Может возвращать false в начальной позиции или после reset итератора
previous():
Возвращает предыдущий элемент и перемещает курсор назад
Выбрасывает NoSuchElementException, если предыдущих элементов нет
Устанавливает состояние для последующего вызова remove() или set()
Внутренние механизмы реализации
Позиционирование курсора
Ключевая концепция ListIterator — курсор, который находится между элементами списка.
Для списка из n элементов существует n+1 возможных позиций курсора:
Позиции курсора: 0 1 2 3 4
Элементы списка: [A] [B] [C] [D]
Семантика операций:
next() возвращает элемент после курсора и перемещает курсор вперед
previous() возвращает элемент перед курсором и перемещает курсор назад
remove() удаляет последний возвращенный элемент
set(E e) заменяет последний возвращенный элемент
Реализация для ArrayList
// Концептуальная реализация для ArrayList
public boolean hasPrevious() {
return cursor > 0;
}
public E previous() {
checkForComodification();
int i = cursor - 1;
if (i < 0) {
throw new NoSuchElementException();
}
Object[] elementData = ArrayList.this.elementData;
if (i >= elementData.length) {
throw new ConcurrentModificationException();
}
cursor = i;
return (E) elementData[lastReturned = i];
}
Особенности:
Использование индекса вместо ссылок на узлы
Проверка границ массива
Обновление lastReturned для поддержки remove() и set()
Реализация для LinkedList
// Концептуальная реализация для LinkedList
public boolean hasPrevious() {
return nextIndex > 0;
}
public E previous() {
checkForComodification();
if (!hasPrevious()) {
throw new NoSuchElementException();
}
lastReturned = next = (next == null) ? last : next.prev;
nextIndex--;
return lastReturned.item;
}
Особенности:
Навигация по ссылкам prev
Обработка граничных условий (первый/последний элемент)
Корректировка next и nextIndex
#Java #для_новичков #beginner #ListIterator
👍2
Особенности производительности
Временная сложность:
ArrayList: O(1) для обеих операций
LinkedList: O(1) для перехода между соседними узлами
Память: Не создает дополнительных объектов при нормальной работе.
Потокобезопасность: Как и другие методы итератора, не является потокобезопасным.
Паттерны использования
Полный двунаправленный обход
Поиск с возвратом
Сравнение соседних элементов
nextIndex() и previousIndex(): Информация о позиции
Концептуальное назначение
Эти методы предоставляют информацию о текущей позиции итератора в списке, что позволяет реализовывать алгоритмы, зависящие от позиции элементов, без необходимости ведения внешних счетчиков или вычислений.
Семантика и поведение
nextIndex():
Возвращает индекс элемента, который будет возвращен следующим вызовом next()
Если итератор находится в конце списка, возвращает размер списка
Не изменяет состояние итератора
previousIndex():
Возвращает индекс элемента, который будет возвращен следующим вызовом previous()
Если итератор находится в начале списка, возвращает -1
Не изменяет состояние итератора
Математическая модель позиционирования
Для списка из n элементов с индексами от 0 до n-1:
Соотношения:
- nextIndex() возвращает индекс курсора
- previousIndex() возвращает (курсор - 1)
- hasNext() = (nextIndex() < n)
- hasPrevious() = (previousIndex() >= 0)
Внутренние механизмы реализации
Базовая реализация
Для ArrayList: Реализация тривиальна, так как позиция хранится как целочисленный индекс.
Для LinkedList: Требуется поддержка счетчика индекса или вычисление позиции через обход.
Поддержка индексации в LinkedList
В LinkedList итератору необходимо поддерживать информацию об индексе:
Где nextIndex обновляется при каждом вызове next() или previous():
next(): увеличивает nextIndex на 1
previous(): уменьшает nextIndex на 1
Особенности производительности
Временная сложность: O(1) для обеих операций во всех реализациях.
Точность: Гарантированно точное значение индекса, соответствующее текущей позиции в списке.
#Java #для_новичков #beginner #ListIterator
Временная сложность:
ArrayList: O(1) для обеих операций
LinkedList: O(1) для перехода между соседними узлами
Память: Не создает дополнительных объектов при нормальной работе.
Потокобезопасность: Как и другие методы итератора, не является потокобезопасным.
Паттерны использования
Полный двунаправленный обход
ListIterator<String> iterator = list.listIterator();
// Движение вперед
while (iterator.hasNext()) {
String element = iterator.next();
processForward(element);
}
// Движение назад
while (iterator.hasPrevious()) {
String element = iterator.previous();
processBackward(element);
}
Поиск с возвратом
public static <T> int findAndReturn(List<T> list, T target) {
ListIterator<T> iterator = list.listIterator();
// Поиск вперед
while (iterator.hasNext()) {
if (iterator.next().equals(target)) {
// Найдено - возвращаемся на две позиции назад
iterator.previous(); // Возвращаемся к найденному элементу
return iterator.previousIndex() + 1;
}
}
return -1; // Не найдено
}Сравнение соседних элементов
public static void processAdjacentPairs(List<Integer> numbers) {
if (numbers.size() < 2) return;
ListIterator<Integer> iterator = numbers.listIterator(1); // Начинаем со второго элемента
while (iterator.hasNext()) {
Integer current = iterator.next();
Integer previous = iterator.previous(); // Переходим к предыдущему
processPair(previous, current);
iterator.next(); // Возвращаемся к текущему для продолжения
}
}nextIndex() и previousIndex(): Информация о позиции
Концептуальное назначение
Эти методы предоставляют информацию о текущей позиции итератора в списке, что позволяет реализовывать алгоритмы, зависящие от позиции элементов, без необходимости ведения внешних счетчиков или вычислений.
Семантика и поведение
nextIndex():
Возвращает индекс элемента, который будет возвращен следующим вызовом next()
Если итератор находится в конце списка, возвращает размер списка
Не изменяет состояние итератора
previousIndex():
Возвращает индекс элемента, который будет возвращен следующим вызовом previous()
Если итератор находится в начале списка, возвращает -1
Не изменяет состояние итератора
Математическая модель позиционирования
Для списка из n элементов с индексами от 0 до n-1:
Индексы элементов: 0 1 2 3
Позиции курсора: 0 1 2 3 4
Соотношения:
- nextIndex() возвращает индекс курсора
- previousIndex() возвращает (курсор - 1)
- hasNext() = (nextIndex() < n)
- hasPrevious() = (previousIndex() >= 0)
Внутренние механизмы реализации
Базовая реализация
// Концептуальная реализация
public int nextIndex() {
return cursor;
}
public int previousIndex() {
return cursor - 1;
}
Для ArrayList: Реализация тривиальна, так как позиция хранится как целочисленный индекс.
Для LinkedList: Требуется поддержка счетчика индекса или вычисление позиции через обход.
Поддержка индексации в LinkedList
В LinkedList итератору необходимо поддерживать информацию об индексе:
public int nextIndex() {
return nextIndex;
}
public int previousIndex() {
return nextIndex - 1;
}Где nextIndex обновляется при каждом вызове next() или previous():
next(): увеличивает nextIndex на 1
previous(): уменьшает nextIndex на 1
Особенности производительности
Временная сложность: O(1) для обеих операций во всех реализациях.
Точность: Гарантированно точное значение индекса, соответствующее текущей позиции в списке.
#Java #для_новичков #beginner #ListIterator
👍2
Паттерны использования
Относительная навигация
Валидация границ
Создание подсписков по позициям
Расширенные методы модификации
set(E e): Замена текущего элемента
Концептуальное назначение
Метод set(E e) позволяет заменить последний элемент, возвращенный вызовом next() или previous(). Это расширяет возможности итератора за пределы простого удаления, позволяя модифицировать содержимое списка во время итерации.
Семантика и поведение
Условия вызова: Может быть вызван только после успешного вызова next() или previous().
Исключения: Выбрасывает IllegalStateException, если не был вызван next() или previous(), или если после последнего вызова next()/previous() был вызван add() или remove().
Эффект: Заменяет элемент в списке без изменения размера коллекции или позиции итератора.
Внутренние механизмы реализации
Общий алгоритм
Реализация для ArrayList
Особенности:
Прямой доступ к массиву по индексу
Проверка границ массива
Сохранение позиции итератора
Реализация для LinkedList
Особенности:
Прямая модификация поля item узла
Не требует поиска узла
Высокая эффективность
Особенности производительности
Временная сложность:
ArrayList: O(1) — прямой доступ по индексу
LinkedList: O(1) — модификация существующего узла
Память: Может создавать новый объект, если заменяемый элемент становится недостижимым.
Потокобезопасность: Не является потокобезопасным.
#Java #для_новичков #beginner #ListIterator
Относительная навигация
public static <T> void processWithRelativeNavigation(List<T> list) {
ListIterator<T> iterator = list.listIterator();
while (iterator.hasNext()) {
int currentIndex = iterator.nextIndex();
T current = iterator.next();
// Обработка с учетом позиции
if (currentIndex % 2 == 0) {
// Четная позиция
processEvenPosition(current, currentIndex);
}
// Пропустить следующие 2 элемента, если возможно
if (iterator.hasNext()) {
iterator.next();
if (iterator.hasNext()) {
iterator.next();
}
}
}
}Валидация границ
public static <T> void safeBidirectionalProcessing(List<T> list) {
ListIterator<T> iterator = list.listIterator();
// Движение вперед с проверкой
while (iterator.hasNext()) {
int nextIdx = iterator.nextIndex();
if (nextIdx < list.size() / 2) {
// Только первая половина списка
T element = iterator.next();
processElement(element);
} else {
break;
}
}
// Движение назад
while (iterator.hasPrevious()) {
int prevIdx = iterator.previousIndex();
if (prevIdx >= 0) {
T element = iterator.previous();
reverseProcess(element);
}
}
}Создание подсписков по позициям
public static <T> List<T> extractSubList(List<T> list, int startIndex, int endIndex) {
List<T> result = new ArrayList<>();
ListIterator<T> iterator = list.listIterator(startIndex);
while (iterator.hasNext() && iterator.nextIndex() < endIndex) {
result.add(iterator.next());
}
return result;
}Расширенные методы модификации
set(E e): Замена текущего элемента
Концептуальное назначение
Метод set(E e) позволяет заменить последний элемент, возвращенный вызовом next() или previous(). Это расширяет возможности итератора за пределы простого удаления, позволяя модифицировать содержимое списка во время итерации.
Семантика и поведение
Условия вызова: Может быть вызван только после успешного вызова next() или previous().
Исключения: Выбрасывает IllegalStateException, если не был вызван next() или previous(), или если после последнего вызова next()/previous() был вызван add() или remove().
Эффект: Заменяет элемент в списке без изменения размера коллекции или позиции итератора.
Внутренние механизмы реализации
Общий алгоритм
public void set(E e) {
if (lastReturned == null) {
throw new IllegalStateException();
}
checkForComodification();
try {
// Замена элемента в списке
list.set(lastReturnedIndex, e);
} catch (IndexOutOfBoundsException ex) {
throw new ConcurrentModificationException();
}
}Реализация для ArrayList
public void set(E e) {
if (lastReturned < 0) {
throw new IllegalStateException();
}
checkForComodification();
try {
ArrayList.this.set(lastReturned, e);
} catch (IndexOutOfBoundsException ex) {
throw new ConcurrentModificationException();
}
}Особенности:
Прямой доступ к массиву по индексу
Проверка границ массива
Сохранение позиции итератора
Реализация для LinkedList
public void set(E e) {
if (lastReturned == null) {
throw new IllegalStateException();
}
checkForComodification();
lastReturned.item = e;
}Особенности:
Прямая модификация поля item узла
Не требует поиска узла
Высокая эффективность
Особенности производительности
Временная сложность:
ArrayList: O(1) — прямой доступ по индексу
LinkedList: O(1) — модификация существующего узла
Память: Может создавать новый объект, если заменяемый элемент становится недостижимым.
Потокобезопасность: Не является потокобезопасным.
#Java #для_новичков #beginner #ListIterator
👍2
Паттерны использования
Модификация элементов на лету
Условная замена
Коррекция данных
add(E e): Вставка нового элемента
Концептуальное назначение
Метод add(E e) представляет собой наиболее мощную операцию ListIterator — он позволяет вставлять новые элементы в список непосредственно перед элементом, который будет возвращен следующим вызовом next(). Это уникальная возможность, недоступная в базовом Iterator.
Семантика и поведение
Позиция вставки: Элемент вставляется перед элементом, который будет возвращен next(), или в конец списка, если next() вернет NoSuchElementException.
Влияние на итератор: После вставки последующий вызов next() вернет новый элемент, а previous() вернет только что вставленный элемент.
Состояние: Сбрасывает состояние lastReturned, поэтому последующий вызов remove() или set() выбросит исключение до следующего вызова next() или previous().
Внутренние механизмы реализации
Общий алгоритм
Реализация для ArrayList
Особенности:
Вызов ArrayList.add(index, element) со сдвигом элементов
Корректировка курсора и счетчиков
Обработка возможного расширения массива
Реализация для LinkedList
Особенности:
Эффективная вставка за O(1) после нахождения позиции
Манипуляции со ссылками между узлами
Автоматическая обработка граничных условий
Особенности производительности
Временная сложность:
ArrayList: O(n) — требуется сдвиг элементов
LinkedList: O(1) — вставка в найденную позицию
Память: Создает новый объект узла (LinkedList) или может вызвать расширение массива (ArrayList).
Потокобезопасность: Не является потокобезопасным.
#Java #для_новичков #beginner #ListIterator
Модификация элементов на лету
public static void transformStrings(List<String> strings) {
ListIterator<String> iterator = strings.listIterator();
while (iterator.hasNext()) {
String original = iterator.next();
String transformed = original.toUpperCase();
iterator.set(transformed);
}
}Условная замена
public static void replaceIf(List<Integer> numbers, Predicate<Integer> condition, Integer replacement) {
ListIterator<Integer> iterator = numbers.listIterator();
while (iterator.hasNext()) {
Integer current = iterator.next();
if (condition.test(current)) {
iterator.set(replacement);
}
}
}Коррекция данных
public static void correctDataSequence(List<DataPoint> data) {
if (data.isEmpty()) return;
ListIterator<DataPoint> iterator = data.listIterator();
DataPoint previous = iterator.next();
while (iterator.hasNext()) {
DataPoint current = iterator.next();
// Коррекция аномальных значений
if (isAnomaly(current, previous)) {
DataPoint corrected = interpolate(previous, current);
iterator.set(corrected);
}
previous = current;
}
}add(E e): Вставка нового элемента
Концептуальное назначение
Метод add(E e) представляет собой наиболее мощную операцию ListIterator — он позволяет вставлять новые элементы в список непосредственно перед элементом, который будет возвращен следующим вызовом next(). Это уникальная возможность, недоступная в базовом Iterator.
Семантика и поведение
Позиция вставки: Элемент вставляется перед элементом, который будет возвращен next(), или в конец списка, если next() вернет NoSuchElementException.
Влияние на итератор: После вставки последующий вызов next() вернет новый элемент, а previous() вернет только что вставленный элемент.
Состояние: Сбрасывает состояние lastReturned, поэтому последующий вызов remove() или set() выбросит исключение до следующего вызова next() или previous().
Внутренние механизмы реализации
Общий алгоритм
public void add(E e) {
checkForComodification();
try {
int i = cursor;
// Вставка в список
list.add(i, e);
// Корректировка состояния итератора
cursor = i + 1;
lastReturned = null;
nextIndex++;
expectedModCount = modCount;
} catch (IndexOutOfBoundsException ex) {
throw new ConcurrentModificationException();
}
}Реализация для ArrayList
public void add(E e) {
checkForComodification();
try {
int i = cursor;
ArrayList.this.add(i, e);
cursor = i + 1;
lastReturned = null;
expectedModCount = modCount;
} catch (IndexOutOfBoundsException ex) {
throw new ConcurrentModificationException();
}
}Особенности:
Вызов ArrayList.add(index, element) со сдвигом элементов
Корректировка курсора и счетчиков
Обработка возможного расширения массива
Реализация для LinkedList
public void add(E e) {
checkForComodification();
lastReturned = null;
if (next == null) {
// Вставка в конец
linkLast(e);
} else {
// Вставка перед next
linkBefore(e, next);
}
nextIndex++;
expectedModCount++;
}Особенности:
Эффективная вставка за O(1) после нахождения позиции
Манипуляции со ссылками между узлами
Автоматическая обработка граничных условий
Особенности производительности
Временная сложность:
ArrayList: O(n) — требуется сдвиг элементов
LinkedList: O(1) — вставка в найденную позицию
Память: Создает новый объект узла (LinkedList) или может вызвать расширение массива (ArrayList).
Потокобезопасность: Не является потокобезопасным.
#Java #для_новичков #beginner #ListIterator
👍2
BiFunction<T, T, T> lookaheadProcessor,
BiFunction<T, T, T> lookbehindProcessor) {
if (list.size() < 2) return;
ListIterator<T> iterator = list.listIterator();
// Обработка с lookahead
while (iterator.hasNext()) {
int currentIndex = iterator.nextIndex();
T current = iterator.next();
if (iterator.hasNext()) {
// Есть следующий элемент для lookahead
T lookahead = iterator.next();
T processed = lookaheadProcessor.apply(current, lookahead);
// Возвращаемся и заменяем текущий элемент
iterator.previous(); // К lookahead
iterator.previous(); // К current
iterator.set(processed);
iterator.next(); // К lookahead
iterator.next(); // К следующему элементу для продолжения
}
}
// Обработка с lookbehind
while (iterator.hasPrevious()) {
T current = iterator.previous();
if (iterator.hasPrevious()) {
T lookbehind = iterator.previous();
T processed = lookbehindProcessor.apply(current, lookbehind);
// Возвращаемся и заменяем
iterator.next(); // К lookbehind
iterator.next(); // К current
iterator.set(processed);
iterator.previous(); // К lookbehind для продолжения
}
}
}
}
Управление состоянием и переходы
Диаграмма состояний ListIterator
Состояния:
1. Инициализация: lastReturned = null, cursor = 0
2. После next(): lastReturned = элемент, cursor = nextIndex
3. После previous(): lastReturned = элемент, cursor = previousIndex + 1
4. После remove(): lastReturned = null
5. После set(): lastReturned остается установленным
6. После add(): lastReturned = null, cursor увеличивается на 1
Допустимые переходы:
- next() → remove() ✓, set() ✓, add() ✓
- previous() → remove() ✓, set() ✓, add() ✓
- remove() → next() ✓, previous() ✓, add() ✗, set() ✗, remove() ✗
- set() → next() ✓, previous() ✓, remove() ✗, add() ✗
- add() → next() ✓, previous() ✓, remove() ✗, set() ✗
Валидация последовательности операций
public class ListIteratorValidator {
public static <T> boolean validateOperationSequence(ListIterator<T> iterator,
List<String> operations) {
boolean canRemoveOrSet = false;
for (String op : operations) {
switch (op) {
case "next":
if (!iterator.hasNext()) return false;
iterator.next();
canRemoveOrSet = true;
break;
case "previous":
if (!iterator.hasPrevious()) return false;
iterator.previous();
canRemoveOrSet = true;
break;
case "remove":
if (!canRemoveOrSet) return false;
iterator.remove();
canRemoveOrSet = false;
break;
case "set":
if (!canRemoveOrSet) return false;
// Необходим элемент для замены
iterator.set(null); // Упрощенная проверка
canRemoveOrSet = false;
break;
case "add":
iterator.add(null); // Всегда допустимо
canRemoveOrSet = false;
break;
default:
return false;
}
}
return true;
}
}#Java #для_новичков #beginner #ListIterator
👍2
Оптимизированные паттерны использования
Эффективное использование для ArrayList
Эффективное использование для LinkedList
#Java #для_новичков #beginner #ListIterator
Эффективное использование для ArrayList
public class ArrayListOptimizations {
// Избегайте частых add() и remove() в середине списка
public static void efficientArrayListProcessing(List<String> list) {
// Вместо множественных add() через ListIterator
// Собирайте изменения и применяйте их пакетно
List<String> toAdd = new ArrayList<>();
ListIterator<String> iterator = list.listIterator();
while (iterator.hasNext()) {
String current = iterator.next();
if (shouldDuplicate(current)) {
toAdd.add(current + "_copy");
}
}
// Пакетное добавление в конец
list.addAll(toAdd);
}
// Используйте set() вместо remove() + add() для замены
public static void replaceEfficiently(List<Integer> numbers) {
ListIterator<Integer> iterator = numbers.listIterator();
while (iterator.hasNext()) {
Integer current = iterator.next();
if (current % 2 == 0) {
iterator.set(current * 2); // Эффективнее, чем remove() + add()
}
}
}
}Эффективное использование для LinkedList
public class LinkedListOptimizations {
// LinkedList идеально подходит для частых вставок/удалений через ListIterator
public static void efficientLinkedListProcessing(LinkedList<String> list) {
ListIterator<String> iterator = list.listIterator();
// Частые вставки эффективны
while (iterator.hasNext()) {
String current = iterator.next();
if (requiresPrefix(current)) {
iterator.add("prefix_" + current);
}
}
// Частые удаления также эффективны
iterator = list.listIterator();
while (iterator.hasNext()) {
if (shouldRemove(iterator.next())) {
iterator.remove();
}
}
}
// Использование previous() для навигации назад
public static void findAndProcessFromEnd(LinkedList<String> list, String target) {
ListIterator<String> iterator = list.listIterator(list.size());
while (iterator.hasPrevious()) {
String current = iterator.previous();
if (current.equals(target)) {
// Нашли - обрабатываем и можем идти в обе стороны
processFound(current);
// Можем продолжить в любом направлении
if (iterator.hasPrevious()) {
processPrevious(iterator.previous());
}
if (iterator.hasNext()) {
processNext(iterator.next());
}
break;
}
}
}
}#Java #для_новичков #beginner #ListIterator
👍2
Best Practices
1. Выбор начальной позиции
2. Минимизация переходов между next() и previous()
3. Использование nextIndex()/previousIndex() для логики, зависящей от позиции
4. Безопасность в многопоточных сценариях
#Java #для_новичков #beginner #ListIterator
1. Выбор начальной позиции
// Начинайте с нужной позиции, а не всегда с начала
ListIterator<T> iterator = list.listIterator(startPosition);
// Для обработки с конца
ListIterator<T> reverseIterator = list.listIterator(list.size());
2. Минимизация переходов между next() и previous()
// Неэффективно:
while (iterator.hasNext()) {
T current = iterator.next();
if (condition(current)) {
iterator.previous(); // Дорогой переход
iterator.add(newElement);
iterator.next(); // Еще один переход
iterator.next(); // Пропускаем добавленный элемент
}
}
// Более эффективно:
while (iterator.hasNext()) {
T current = iterator.next();
if (condition(current)) {
iterator.add(newElement);
// current остался тем же, newElement теперь перед ним
}
}
3. Использование nextIndex()/previousIndex() для логики, зависящей от позиции
ListIterator<T> iterator = list.listIterator();
while (iterator.hasNext()) {
int currentIndex = iterator.nextIndex();
T element = iterator.next();
if (currentIndex % 2 == 0) {
// Обработка четных позиций
processEven(element, currentIndex);
}
}
4. Безопасность в многопоточных сценариях
// Всегда синхронизируйте доступ к ListIterator
synchronized(list) {
ListIterator<T> iterator = list.listIterator();
while (iterator.hasNext()) {
// Обработка
}
}
// Или используйте потокобезопасные альтернативы
List<T> syncList = Collections.synchronizedList(new ArrayList<>());
// Но даже synchronizedList требует внешней синхронизации для итерации
#Java #для_новичков #beginner #ListIterator
👍2