Краткий ответ

instanceof разрешает проверять только reifiable-типы — типы, чья информация доступна во время выполнения. Поэтому проверка на List<?> допустима, а проверка на List<String> запрещена компилятором: после стирания JVM видит только List и не может отличить список строк от списка чисел.

Проверка instanceof List<?> подтверждает лишь, что объект является списком. Она не подтверждает тип его элементов; элементы нужно проверять отдельно.

Исторический контекст

Обобщения появились в Java 5, при этом Java сохранила совместимость с большим количеством существующего кода и библиотек. Для этого параметризация типов в основном реализована через стирание типов: сведения о конкретных аргументах обобщённого типа используются компилятором, но не сохраняются в обычном виде для проверок JVM.

Такой подход позволяет старому байткоду взаимодействовать с новым кодом, но ограничивает проверки параметризованных типов во время выполнения. В частности, JVM может проверить факт принадлежности объекта к List, но не узнать, был ли он объявлен как List<String> или List<Integer>.

Постановка проблемы

Предположим, метод получает Object и должен понять, является ли значение списком. Проверка только на List не сообщает, какие элементы находятся внутри, а попытка проверить List<String> напрямую невозможна.

Неверное предположение особенно опасно на границах приложения: после непроверенного приведения ошибка проявится не в месте получения данных, а позже — например, при чтении элемента и приведении его к String. Это усложняет диагностику и может привести к ClassCastException.

Подробное решение

В Java допустимы проверки на сам обобщённый класс без аргументов, например List, и на параметризованный тип с неограниченными wildcard, например List<?>. Оба варианта являются reifiable, но List<?> лучше выражает намерение: объект должен быть списком с неизвестным типом элементов.

Проверка на List<String> запрещена, поскольку String не сохраняется в типе объекта после стирания. Аналогично нельзя надёжно выполнить проверку на произвольный параметр типа или на параметризованный тип с конкретным bound.

import java.util.List;

class TypeCheckDemo {
    static boolean isList(Object value) {
        return value instanceof List<?>;
    }

    static void inspect(Object value) {
        if (value instanceof List<?>) {
            List<?> list = (List<?>) value;
            Object first = list.isEmpty() ? null : list.get(0);
        }
    }

    // value instanceof List<String> // ошибка компиляции
}

После проверки List<?> чтение элемента даёт значение типа Object, потому что конкретный тип неизвестен. Добавлять произвольные значения в такую коллекцию нельзя, кроме null: неизвестно, какой именно тип элементов она принимает.

Приведение объекта к List<String> может быть синтаксически разрешено, но обычно сопровождается unchecked warning. Во время выполнения проверяется только факт, что объект — это список; проверка каждого элемента на String не выполняется автоматически.

Если требуется подтвердить тип элементов, нужно отдельно пройти по коллекции, проверить каждый элемент и, как правило, создать типобезопасную копию. Это требует дополнительных затрат, зато переносит ошибку к границе входных данных и предотвращает скрытое распространение небезопасной коллекции.

Ситуация из практики

Сервис получает результат десериализации как Object и должен принять только список строк. Рассматривались два варианта: выполнить непроверенное приведение к List<String> или сначала проверить объект как List<?>, затем проверить каждый элемент.

Непроверенное приведение короче и не требует копирования, но не валидирует элементы. Некорректные данные могут пройти дальше и вызвать ClassCastException в другом компоненте.

Выбран второй вариант: сначала проверяется List<?>, затем каждый элемент проверяется на String, после чего создаётся новая List<String>. Это требует времени O(n) и дополнительной памяти O(n), но создаёт ясную границу валидации и позволяет остальному коду работать без unchecked-приведений.

Что кандидаты часто упускают

Вопрос: Что именно гарантирует проверка instanceof List<?>?

Ответ: Она гарантирует только, что ссылка указывает на объект, совместимый с List. Тип элементов не проверяется и не становится известным компилятору. Поэтому результат чтения имеет тип Object, а не String или другой конкретный тип.
Вопрос: Чем проверка instanceof List хуже проверки instanceof List<?>, если обе разрешены?

Ответ: На уровне выполнения они проверяют один и тот же факт — принадлежность объекта к List. Однако List — raw-тип, который скрывает отсутствие информации о параметре и может вызывать предупреждения при включённой диагностике raw-типов. List<?> явно фиксирует безопасную модель: список существует, но тип его элементов неизвестен.
Вопрос: Почему приведение к List<String> иногда компилируется, хотя проверка instanceof List<String> запрещена?

Ответ: Приведение может быть принято компилятором как потенциально допустимое, но с предупреждением unchecked, поскольку компилятор не способен доказать безопасность операции. В runtime-проверке такого приведения участвует только сырой класс List; параметр String не проверяется. Поэтому такое приведение не восстанавливает фактическую информацию о типе элементов и безопасно только при наличии внешней гарантии или предварительной явной валидации.