Лямбды и функциональные интерфейсы

Что такое функциональный интерфейс

Загляни в байткод того же файла. На месте лямбды стоит инструкция invokedynamic, на месте анонимного класса - new L1$1. Анонимный класс создаётся как обычный объект заранее известного класса; лямбда собирается рантаймом при первом исполнении, и отдельного класса под неё в jar-файле нет.

Функциональный интерфейс - интерфейс ровно с одним абстрактным методом, то есть методом без тела. Именно по нему компилятор понимает, во что превращать лямбду: раз метод один, догадываться не о чем. Аннотация @FunctionalInterface - страховка от коллеги, который добавит второй метод и сломает все лямбды разом.

Готовый словарь лежит в java.util.function и покрывает почти все сигнатуры: Function<T,R> преобразует одно в другое, Predicate<T> проверяет условие и возвращает да или нет, Consumer<T> что-то делает со значением и ничего не возвращает, Supplier<T> наоборот - выдаёт значение, ничего не принимая. Плюс Bi-версии на два аргумента и UnaryOperator, когда тип на входе и выходе один.

Runnable lambda = () -> System.out.println("л");
Runnable anon = new Runnable() { public void run() { System.out.println("а"); } };

// после javac на диске: L1.class и L1$1.class - второй это анонимный класс
// в байткоде: invokedynamic #7  //  лямбда
//             new #11 // class L1$1  -  анонимный класс

функциональный интерфейс

интерфейс ровно с одним абстрактным методом

invokedynamic

инструкция, которой JVM собирает лямбду на лету, без отдельного класса

Ссылка на метод и подмена перегрузки

Взял список из одного массива символов {'д','а'} и применил map(String::valueOf). Получил [да]. А если бы тот же массив ушёл в String.valueOf((Object) chars), вышло бы [C@6989da5e - адрес объекта вместо текста.

Разница в том, какую из перегрузок метода выбрал компилятор: у String.valueOf есть версия под char[] и версия под Object, и выбирается она по типу, известному на компиляции. Ссылка на метод (её пишут через двойное двоеточие) этот выбор не показывает - его надо держать в голове.

Форм ссылки четыре. Тип::статическийМетод. объект::метод - на конкретном уже существующем объекте. Тип::методЭкземпляра - тут первый аргумент становится тем объектом, у которого метод зовут: String::length читается как s -> s.length(), а String::compareTo как (a, b) -> a.compareTo(b). И Тип::new - конструктор. Собранное поведение при этом передаётся как обычное значение: f.andThen(g) сделает сначала f, потом g, f.compose(g) наоборот, а у предикатов есть and, or и negate.

ссылка на метод

запись через двойное двоеточие вместо лямбды-обёртки

andThen / compose

склейка функций: после / до

Захват переменных и почему счётчик не работает

Попробовал собрать счётчик прямо в лямбде - int count = 0; list.forEach(x -> count++). Компилятор отказал дословно: local variables referenced from a lambda expression must be final or effectively final.

Effectively final означает «фактически неизменяемая»: переменной присвоили значение один раз и больше не переприсваивали, даже если слово final не написано. Требование не про строгость, а про время жизни. Локальная переменная лежит в стеке метода, а лямбда может исполниться позже, когда метод давно закончился, или вообще в другом потоке. Поэтому захватывается копия значения, и компилятор следит, чтобы копия не разошлась с оригиналом.

Известная лазейка - завести массив из одного элемента: int[] counter = {0}, ссылка-то не меняется. Я прогнал такой счётчик на 200 000 параллельных увеличений три раза: 194517, потом 200000, потом снова 200000. То есть гонка тут настоящая, но показывается через раз - и это худший вид ошибки, который проходит тесты и падает на проде. Честные способы посчитать - обычный цикл, reduce или счётный коллектор.

int count = 0;
list.forEach(x -> count++);
// error: local variables referenced from a lambda expression
//        must be final or effectively final

int[] counter = {0};                 // компилируется, но это гонка
// 200 000 увеличений параллельно: 194517, 200000, 200000

effectively final

переменная, которой присвоили значение один раз и не меняли

Как отвечать: «Почему в лямбде нельзя менять локальную переменную снаружи?»

Потому что лямбда захватывает не саму переменную, а её значение. Локальная переменная живёт в стеке метода, в его фрейме - так называют кусок стека, который метод занимает на время работы и освобождает на выходе. Лямбда может сработать позже, когда фрейм уже освобождён, или в другом потоке. Компилятор поэтому требует effectively final - чтобы переменную присвоили один раз и не меняли, тогда захваченная копия гарантированно совпадает с оригиналом. Формулировка ошибки прямая: local variables referenced from a lambda expression must be final or effectively final. Обходной приём с массивом из одного элемента компилируется, потому что неизменна ссылка, но я так не делаю: на параллельном стриме это гонка, и я её ловил - из 200 тысяч увеличений один прогон дал 194 тысячи, а два соседних отработали правильно. Нужен счётчик или накопитель - беру reduce или коллектор, они спроектированы под корректное слияние.

Почему это сильный ответ: названа причина через время жизни стека и потоки, а не пересказано правило; разобран популярный обходной приём и показано, чем он опасен именно на практике.

На чём валят

• −Менять локальную переменную из лямбды. Не скомпилируется, а приём с массивом из одного элемента даёт гонку, которая проявляется через раз.
• −Ждать, что checked-исключение вылетит наружу из стрима. Function его не объявляет, компилятор скажет unreported exception - оборачивай внутри лямбды.
• −Путать this. Внутри лямбды это объект окружающего класса, внутри анонимного класса - сам анонимный объект.
• −Ссылка на метод с перегрузками. String::valueOf на массиве символов даёт текст, а через Object дал бы адрес объекта - выбор перегрузки в записи не виден.
• −Побочные действия в лямбдах параллельных операций. Конвейер должен быть чистым, иначе получаешь гонку.