Java Interview Review

Как сгенерировать уникальный идентификатор?

UUID (universally unique identifier) – стандарт, описывающий способ создания правильных уникальных идентификаторов. Значения генерируются на основании таких источников информации, как системное время и MAC-адрес, за счет чего они остаются с достаточной вероятностью уникальными, даже будучи сгенерированными независимо. Можно с разных машин добавлять в базу данных записи с UUID-идентификаторами, и не бояться конфликта.

UUID бывает пяти разных версий, версия определяет способ создания. Формат остается одинаковым: это строковое шестнадцатеричное представление 128-битного целого числа (два long-а), разделенное дефисами на группы фиксированного размера:

25b32eaa-3017-4ad7-9224-383f6bfa5212

В Java уникальный идентификатор представляется иммутабельным классом UUID из пакета java.util. В нём нет сложной логики, только getter-ы для описанных в стандарте составных частей, конструктор и статические фабричные методы.

Единственный конструктор позволяет создать экземпляр по двум указанным половинам значения (старшие и младшие 64 бита в виде long параметров). nameUUIDFromBytes строит из заданного массива байтов UUID версии 3. randomUUID генерирует случайный уникальный идентификатор версии 4, с применением SecureRandom.

#Классы

Как написать на Java UDP-сервер?

Естественно, сначала необходимо разобраться, что такое UDP. Упрощая, User Datagram Protocol – это альтернатива TCP, когда информацию нужно слать быстро, много, и при этом допустимы потери и дублирование данных. Типичные примеры использования – потоковое видео и аудио, интернет-телефония, торренты.

В Java данные, которые планируется отправить клиентам по протоколу UDP, упаковываются в объект класса DatagramPacket. В виде массива байтов их передают в конструктор.

Для отправки и получения информации используется DatagramSocket. Он похож на ServerSocket, который применяют для создания TCP-сервера. Для приёма сообщений используется блокирующий метод receive, для отправки – send. Примечательно, что оба метода принимают DatagramPacket параметром. В случае receive его байтовый массив заполняется пришедшими данными.

Для реализации клиентской стороны используется тот же самый DatagramSocket. Просто он создается несвязанным (unbound) – в его конструкторе не указывается порт. Адрес и порт, на которые нужно отправить сообщение, устанавливаются через конструктор DatagramPacket.

В Java NIO доступна версия UDP-сокета в виде канала – DatagramChannel.

#Сеть

Как прочитать InputStream в строку?

Обычно строковые данные извне попадают в программу именно в виде потока. Потоком читаются файлы, сетевые данные из сокета, пользовательский ввод. Если есть такая возможность, лучше избегать сохранения потоковых данных в память, и обрабатывать их также в потоке. Например, когда из большого xml-файла необходимо достать один определенный элемент, имеет смысл выбрать потоковый xml-парсер.

В общем виде все решения выглядят так. Заводится буфер – массив символов. Поток направляется в этот буфер. По заполнению данные из массива присоединяются в хвост строки-результата.

Простой способ – использовать трюк со сканером. Вообще класс Scanner читает из потока подстроки, разделенные указанным символом. Когда нужно прочитать всю строку сразу, в качестве разделителя устанавливается "\\A" – спецсимвол «начало строки». Это решение просто в реализации, но имеет проблемы. Размер внутреннего буфера фиксирован (1024 символа), а логика поиска разделителя плохо влияет на производительность.

Хорошее решение для продакшна – читать в собственный массив-буфер непосредственно методом InputStream.read, либо обернув поток в InputStreamReader. Данные из буфера затем переправляются в строку через StringBuilder или ByteArrayOutputStream. За готовой реализацией можно обратиться в библиотеки Apache Commons IO и Google Guava. Полный код реализации и сравнение производительности описаны на stackoverflow.

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

#Строки

​Из каких основных сущностей состоит Spring-приложение? (2/2)

Реализация интерфейса ApplicationContext – основное хранилище конфигурации Spring-приложения (или его части). Контекст неизменяем, но может быть целиком перезагружен. Xml-файл конфигурации на старте приложения превращается в объект *XmlApplicationContext. Для конфигурации на аннотациях создастся AnnotationConfigApplicationContext. Контекст выполняет четыре разных обязанности:

1. DI-контейнер. ApplicationContext функционирует как специальная реализация BeanFactory. Он также производит и хранит бины, но, в отличие от обычных фабрик, контексты в приложении составляют иерархию. Определения бинов из дочерних контекстов перекрывают родительские.

2. Загрузка ресурсов. Под интерфейсом ResourceLoader контекст занимается загрузкой в память приложения файлов, как из classpath, так и из остальной файловой системы.

3. Публикация событий приложения. Контекст распространяет в приложении «события» – наследники ApplicationEvent. Любой бин, которому нужно получать уведомления об этих событиях, просто реализует интерфейс ApplicationListener. Таким образом реализуется паттерн наблюдатель.

4. Интернационализация. По коду, набору аргументов и локали, через интерфейс контекста MessageSource можно получать локализованные текстовые сообщения для пользователей.

#Spring

Из каких основных сущностей состоит Spring-приложение? (1/2)

Bean – объект бизнес-логики в терминологии Spring Framework.

BeanDefinition – описание того, как создавать бин. Объект хранит его тип, метаинформацию, набор параметров для конструктора.

BeanFactory – главная точка входа в DI-контейнер. Хранит BeanDefinition-ы, умеет создавать по ним экземпляры бинов, или выдавать существующие, в зависимости от скоупа.

BeanPostProcessor – донастраивает только что созданные бины, перед тем как положить их в контейнер. Его методы уже упоминались в публикации про жизненный цикл. Типичное место, чтобы оборачивать бины в прокси. Также с помощью такого пост-процессора внедряются @Autowired-зависимости. Пост-процессоры бинов живут внутри экземпляра BeanFactory.

BeanFactoryPostProcessor – тоже пост-обработчик, но для определений бинов (BeanDefinition). Обычно используется для модификации параметров или класса, из которых будут строиться бины.

Для создания определений бинов в основном применяются классы и интерфейсы *BeanDefinitionReader. Некоторые из них вызываются прямо из контекста приложения, другие реализуют BeanFactoryPostProcessor. Один такой пост-процессор, например, отвечает за добавление определений бинов по аннотациям @Component и @Configuration.

#Spring

Какой выбрать тип для даты/времени?

В пакете java.util расположены старые классы стандартной библиотеки Java: Date (дата+время), Calendar (конвертация и манипуляция), TimeZone (смещение часового пояса). Эти классы обладали рядом известных проблем. Экземпляры были изменяемыми, что делало их потоко-небезопасными. Работа с датами через календарь была неудобной, не было нормальной поддержки часовых поясов и интернационализации.

Постепенно стандартом де-факто стала сторонняя библиотека Joda-Time. Её разработчики решили все названные выше проблемы.

В Java 8 был добавлен пакет java.time, который взял решения из Joda-Time в стандарт, создатель библиотеки участвовал в разработке. Ключевые классы пакета:
• LocalDate, LocalTime и LocalDateTime – локальные для пользователя дата/время.
• ZonedDateTime – дата/время в определенной часовой зоне.
• Period и Duration – периоды дат и времени соответственно.

Отдельно существуют классы Date и Time пакета java.sql. Это представление даты и времени для обмена данными через JDBC. Не стоит пользоваться ими вне уровня доступа к данным, хотя бы потому, что это классы-наследники старого java.util.Date.

Таким образом, в проектах на Java 8+ нужно использовать современные java.time.*, для более старых – подключать Joda-Time.

#Классы

Как остановить поток?

В Java поток представлен классом Thread. В нём есть метод stop(), но пользоваться им нельзя, метод помечен как deprecated. Такая жесткая остановка моментально возвращает все захваченные потоком мониторы, и защищенные ими данные могут оказаться в неконсистентном состоянии.

Разработчики рекомендуют вместо этого использовать флаг, который будет показывать о намерении остановить поток. Флаг выставляется извне потока, а внутри проверяется в подходящий момент. Если нужно остановиться, поток просто выходит из метода run(). В качестве такого флага подойдет переменная типа AtomicBoolean.

Когда в потоке используются блокирующие операции, обычно для определенного типа операции существует свой способ её прервать. Например, можно закрыть сокет, на котором поток ожидает. Для большинства блокирующих операций сработает метод Thread.interrupt(). С его помощью можно прервать Object.wait() и операции из NIO.

Останется только правильно обработать такое прерывание. Прерванный wait() выбросит InterruptedException, Selector.select() вернет результат. Чтобы отличить осознанное прерывание с целью завершить тред от какого-либо другого, его обработку всё ещё необходимо снабдить проверкой флага.

#Многопоточность

Как сравнивать элементы перечисления?

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

Скомпилированный класс неявно наследуется от java.lang.Enum, в котором все методы из Object кроме toString объявлены финальными. В частности, невозможно изменить поведение метода equals – он сравнивает enum-ы с помощью ==. Так что equals тоже можно использовать без опаски.

Но помимо этого есть несколько отличий в пользу ==:

1. == не выбросит NullPointerException. Прежде чем вызывать equals у переменной, придется удостовериться что она не null.

2. == не позволит сравнить объекты разных типов. Оператор еще на этапе компиляции подскажет, что такое сравнение не имеет смысла. equals же будет принимать аргумент под типом Object, и всегда возвращать false уже в рантайме.

3. == быстрее. Скорее всего разница в производительности будет незаметной, но тем не менее, оператор не требует лишнего вызова метода.

#Язык

Какой способ логирования выбрать?

Библиотеки логирования, ставшие стандартом де-факто, в хронологическом порядке их появления:

• java.util.Logging из стандартной библиотеки
• Log4j (deprecated)
• Logback
• Log4j 2

Все эти библиотеки поддерживают основные фичи: уровни логирования (что писать), различные хэндлеры (куда писать), форматы (как писать). Развитие библиотек происходило последовательно, в нюансах каждая из них учитывала ошибки предыдущей, сохраняя её преимущества. Обычно выбирают самые свежие варианты – Logback и Log4j 2.

Для совмещения нескольких решений в одном проекте существуют библиотеки-фасады, которые подставляют разные реализации под общий интерфейс:
• SLF4j
• Apache Commons Logging (JCL)

Кроме того, можно использовать bridge-библиотеки. Они маскируют одну реализацию непосредственно под интерфейс другой. С их помощью, например, можно уместить в одном проекте использование двух разных фасадов, или обойтись вовсе без фасадов.

Для более глубокого погружения в вопрос библиотек логирования рекомендуется к просмотру этот доклад.

#Инструменты

Что такое fail-fast и fail-safe итераторы?

Это не какие-то отдельные типы, а характеристики разных реализаций интерфейса Iterator. Они определяют, как поведет себя итератор при изменении перебираемой последовательности.

Fail-fast – «быстрый» итератор. Когда после его создания коллекция как-либо изменилась, он падает с ошибкой без лишних разбирательств. Так работает итератор класса ArrayList, при изменении он выбрасывает ConcurrentModificationException. Рекомендуется не основывать логику программы на fail-fast отказах, и использовать их только как признак ошибки реализации.

Fail-safe – «умный» итератор. Обычно плата за отказоустойчивость – возможная неконсистентность данных («слабая консистентность»). Итератор класса ConcurrentHashMap работает с копией данных, он не выбросит исключение при изменении коллекции, но может не увидеть часть свежих изменений. Плата за отсутствие ошибок других fail-safe итераторов может отличаться, детали всегда можно найти в документации коллекций.

#Коллекции