Telegram Web Link
🧠 Если вы хотите переопределить equals(), какие условия должны выполняться?

- Рефлексивность: для любой ссылки на значение x, x.equals(x) вернет true;

- Симметричность: для любых ссылок на значения x и y, x.equals(y) должно вернуть true, тогда и только тогда, когда y.equals(x) возвращает true.

- Транзитивность: для любых ссылок на значения x, y и z, если x.equals(y) и y.equals(z) возвращают true, тогда и x.equals(z) вернёт true;

- Непротиворечивость: для любых ссылок на значения х и у, если несколько раз вызвать х.equals(y), постоянно будет возвращаться значение true либо постоянно будет возвращаться значение false при условии, что никакая информация, используемая при сравнении объектов, не поменялась.

-Для любой ненулевой ссылки на значение х выражение х.equals(null) должно возвращать false.

На картинкее приведен пример, по которому все будет понятно, также не надо забывать, что при переопределении метода equals() необходимо переопределить метод hashCode().

@javatg
Вопросы по Java на собеседовании

Использование метода join

Метод join позволяет текущему потоку «приостановить» выполнение своего кода и «пропустить» вперед другой поток.

В следующем примере в методе main, выполняющего роль главного потока приложения, создается и стартует отдельный (дочерний) поток объекта ThreadClass. При выполнении метода run поток объекта TestClass приостанавливает свое выполнение на 5 сек. В это время основной поток вызывает метод join() и пропускает вперед дочерний поток. Несмотря на то, что дочерний поток перешел в режим ожидания, основной поток продолжает ожидать его завершения. После завершения функционирования дочернего потока сразу же завершает свою работу и основной поток.

В консоль выводит свое сообщение сначала дочерний поток и переходит в режим ожидания на 5 сек (картинка 2). Через 5 сек. дочерний поток, а следом и основной поток завершают свою работу.

@javatg
Каким будет результат выполнения кода?

Ответ

@javatg
В чём разница между jar и war?

jar и war – расширения платформо-независимых файлов-архивов Java-приложения. Кроме них есть еще третий формат, ear. Все эти форматы – на самом деле просто zip-архивы с классами и другими частями приложения. Вы можете переименовать такой файл в .zip, разархивировать, и посмотреть, что внутри.

JAR – Java Archive. Содержит файлы классов, ресурсы, зависимые библиотеки, и другие необходимые для приложения файлы. Может содержать точку входа, и использоваться как цель для исполнения команды java.

WAR – Web Archive. Технически имеет ту же структуру, но другую роль – архив JavaEE web-компонента. Обычно содержит jar-ы с реализацией, JSP, статические файлы фронт-энда, и мета-информацию для сервлет-контейнера (web.xml). В основном используется как деплоймент web-приложения в сервлет-контейнер. С приходом Servlet API 3.0 и embedded-контейнеров, всё больше становится принято запаковывать и web-компоненты в самодостаточные jar (Лозунг Spring Boot: Make jar, not war).

EAR – Enterprise Archive. Для разработчиков, начавших карьеру уже во времена Spring Framework, может показаться совсем экзотичным. Это собранное воедино монолитное JavaEE приложение. Содержит дескрипторы деплоймента и JavaEE модули (веб-модули, EJB, клиентские модули, адаптеры ресурсов). Деплоится в JavaEE Application Server.

Все три типа файлов собираются утилитой jar из JDK.

#Инструменты
Наш партнер, школа онлайн-обучения Java, приглашает на летнюю стажировку Enterprise Java-разработчик (TopJava) по самой ранней цене, старт 26 мая🚀. Открытое первое занятие по ссылке: https://javaops.ru/view/topjava?ref=javatg
Каким будет результат выполнения кода?

Ответ

@javatg
Бывают ли в Java утечки памяти? (1/2)

Сначала стоит сказать, что это такое. Утечка памяти (memory leak) в широком смысле – потеря доступа к некоторой сущности, которая при этом всё еще остается «живой» и расходует ресурсы компьютера.

Основное отличие Java от языков вроде C – автоматическое управление памятью. В общем случае вам не нужно думать об удалении объекта из памяти. Когда он перестал быть нужен, сборщик мусора сделает это за вас.

Но всё-таки бывают случаи, когда JVM не способна помочь, и прибираться за собой нужно вручную:

1. Объекты в статических полях. Обычно они живут пока живёт класслоадер, который обычно живет до конца работы приложения. В эту же группу риска попадают синглтоны, которые обычно базируются на статиках. Отдельного внимания заслуживает случай утечки ThreadLocal.

2. Взаимодействие с нативным кодом и ручное управление памятью. Когда вы решаетесь на ручное/внешнее управление, вся ответственность за сборку мусора переходит на вас. Это касается использования Unsafe и нативных библиотек. Сюда же попадают различные утечки внешних ресурсов: например соединений с базой через нативный драйвер.

3. Неправильное использование коллекций. Несогласованность методов equals-hashCode может позволить ключам теряться внутри HashMap/HashSet. Размер зарезервированной памяти часто не совпадает с размером содержимого: тот же HashMap, однажды раздувшись, не умеет уменьшаться.

#JVM

@javatg
Зачем выбирать ReentrantLock вместо synchronized?

Объект класса ReentrantLock решает те же задачи, что и блок synchronized. Поток висит на вызове метода lock() в ожидании своей очереди занять этот объект. Владеть локом, как и находиться внутри блока synchronized может только один поток одновременно. unlock(), подобно выходу из блока синхронизации, освобождает объект-монитор для других потоков.

В отличие от блока синхронизации, ReentrantLock дает расширенный интерфейс для получения информации о состоянии блокировки. Методы лока позволяют еще до блокировки узнать, занят ли он сейчас, сколько потоков ждут его в очереди, сколько раз подряд текущий поток завладел им.

Шире и возможные режимы блокировки. Кроме обычного ожидающего lock(), вариант tryLock() с параметром ожидает своей очереди только заданное время, а без параметра – вообще не ждет, а только захватывает свободный лок.

Еще одно отличие – свойство fair. Лок с этим свойством обеспечивает «справедливость» очереди: пришедший раньше поток захватывает объект раньше. Блок synchronized не дает никаких гарантий порядка.

#Многопоточность
#Классы
Как отладить удаленное приложение?

Если приложение работает не в продакшне, его паузы допустимы, а у потенциального злоумышленника нет сетевого доступа к хосту, стандартный способ отладки – непосредственно remote debug. Для этого приложение запускается с включенным протоколом удаленной отладки JDWP. Приложение принимает на указанный порт подключения отладчика. Это может быть отдельная утилита jdb, или встроенная в IDE.

В JDK поставляется набор инструментов для мониторинга. Например Java Mission Control и JConsole позволяют подключиться к приложению и посмотреть множество показателей его здоровья. Полный список инструментов специфичен для конкретной JVM, для HotSpot можно посмотреть в документации.

Вне зависимости от обстоятельств, всегда необходимо заранее позаботиться о диагностической информации номер один – логах. Как минимум, ни один встроенный инструмент не покажет вам информацию о событиях, определяемых бизнес-логикой вашего приложения. Логироваться должен необходимый минимум, который позволит при любом инциденте понять, что произошло.

В стандартную поставку Java включен пакет для логгирования java.util.logging, позже остановимся на нём подробнее. Также существует ряд популярных библиотек: Log4j, SLF4J, Logback. Про техники и сложности логгирования современного энтерпрайза есть неплохой доклад.

#Инструменты
Как используется метод Lock.newCondition()?

Если реализации интерфейса Lock представляют высокоуровневую альтернативу блока synchronized, то реализации его спутника, интерфейса Condition – альтернатива методам notify/wait. Оба этих интерфейса относятся к пакету java.util.concurrent.locks.

Как и ожидание на мониторе, Condition реализует примитив синхронизации «Условная переменная». Один или несколько потоков зависают на объекте-кондишне с помощью варианта метода await (ждут удовлетворения условия). Другой поток пробуждает их методами signal и signalAll (сигнализирует об удовлетворении условия).

Конкретные реализации Condition всегда решают те же задачи, что блокировка на мониторе, но в теории могут отличаться в нюансах поведения. Например, может не быть требования вызывать ожидание/сигнал только при захваченном локе (аналог требования, по которому notify/wait всегда вызываются в synchronized). Или может гарантироваться порядок получения сигнала ожидающими потоками.

Возвращаясь к поставленному вопросу, Condition всегда связан со своим объектом типа Lock, и метод Lock.newCondition() – единственный правильный способ создания кондишна.

#Многопоточность
#Классы

@javatg
Как получить текущий метод

В общем виде задача сводится к получению текущего стек-трейса, и взятию его верхнего элемента. Гарантированного способа не существует, потому что JVM имеет право «терять» фреймы стека (то есть методы цепочки вызовов) при оптимизации.

1. new Exception().printStackTrace(printStream)
Печатает стек-трейс в текстовом виде в поток. Первой строкой выводится toString() объекта Exception, далее стек вызовов до места создания исключения. Соответственно, из потока нужно будет достать и распарсить вторую строку. В зависимости от JVM формат вывода может отличаться.

2. Thread.currentThread().getStackTrace()
3. new Exception().getStackTrace()
Более красивые способы. Возвращают уже массив готовых объектов-фреймов, нужно только взять первый элемент. Эти вызовы дорогие, они всегда загружают весь стек, даже если нужен первый фрейм. От класса-владельца метода в возвращаемом StackTraceElement доступна только строка имени, для доступа через Reflection придется загружать его вручную.

4. StackWalker.getInstance(options, depth).walk(s -> ...)
Самый продвинутый способ, доступный с Java 9 – специально предназначенный для этого класс. Параметрами метода getInstance() можно ограничивать необходимую глубину и детализацию стека. Результаты – экземпляры StackFrame – содержат готовый для рефлекшна Class<?> вызывающего объекта.

#Классы

@javatg
Чем отличается Servlet Container от Application Server?

JavaEE – это стандарт, набор соглашений. Разделяется на множество отдельных самостоятельных спецификаций технологий. В JDK поставляется в виде только интерфейсов и документации, но не их реализации.

Application Server – это полная реализация всех спецификаций стандарта JavaEE: распределенные транзакции, EJB, пуллинг соединений к БД и т.д.. Используется для хостинга полноценных enterprise-приложений (.ear). Примеры – JBoss, TomEE, Glassfish, WebSphere.

Servlet Container (web server) – это реализация минимальной необходимой части JavaEE – Servlet API и JSP. Умеет хостить статический контент, jsp-страницы и выполнять Java код сервлетов. Остальные спецификации JavaEE при необходимости добавляются сторонними библиотеками-реализациями. Примеры – Tomcat, Jetty.

Каждый сервер приложений содержит в себе контейнер сервлетов. Spring Framework – альтернатива JEE, поэтому для запуска приложения на основе Spring обычно достаточно веб-контейнера. Если же приложение использует всю мощь JEE, необходим сервер приложений.

#JavaEE

@javatg
Что выбрать, Stack или Queue?

Queue – один из основных интерфейсов Java Collections Framework. В общем случае (но не обязательно) представляет FIFO-коллекцию – элементы можно добавлять в хвост, брать или удалять из головы. Его наследник, интерфейс Deque (double ended queue, двусторонняя очередь), позволяет манипулировать элементами на обеих сторонах.

StackLIFO коллекция. То есть добавлять и удалять элементы можно только с одного конца. Кроме того, стек наследуется от Vector, и тоже является пересинхронизированным и устаревшим. Его документация явно рекомендует предпочесть использовать Deque.

#Коллекции

@javatg
Из каких технологий состоит JavaEE?

Технологии актуальной версии JavaEE 8 разделяют на пять групп.

#JavaEE

@javatg
Как Spring Framework реализует паттерн Dependency Injection?

Инверсия контроля (inversion of control, IoC) – принцип проектирования, по которому контроль над потоком управления передается фреймворку. Управляющий и прикладной код разделяются. При разработке модуля этот подход избавляет от необходимости знать о других модулях программы и деталях их взаимодействия. Такой код становится более переипользуемым и модульным, уменьшает связность.

Внедрение зависимостей (Dependency Injection, DI) – одна из реализаций IoC. При взаимодействии с другими модулями, программа оперирует высокоуровневыми абстракциями, тогда как конкретная её реализация поставляется фреймворком.

Стандартная реализация DI – фреймворк инстанциирует все сервисы, и складывает их в IoC-контейнер. При этом специальная сущность, Service Locator, занимается поиском соответствия реализаций абстракциям и их внедрением.

Spring – большой набор различных библиотек. DI реализуется одной из основных библиотек – Spring IoC.

Сущности бизнес-логики в Spring, как и в JavaEE называются beans. Бины объявляются различными способами, корни большинства из них лежат в понятии Configuration. В качестве контейнера бинов выступает ApplicationContext. Чтобы передать инициализацию зависимости контексту, она помечается аннотацией @Autowired.

Лучше разобраться в понятиях экосистемы Spring поможет известный доклад Евгения Борисова «Spring-потрошитель»:часть 1,часть 2.

#Spring
https://www.tg-me.com/itchannels_telegram - подборка лучших ит-каналов и чатов, разбитые по языкам программирования.
Что делает семафор?

Семафор – один из старейших примитивов синхронизации. Он был изобретен Дейкстрой в 1968 году. По большому счету это счетчик, который можно увеличивать и уменьшать из разных потоков. Уменьшение до 0 блокирует уменьшающий поток. Состояние, когда счетчик больше нуля называют сигнальное состояние, операцию его увеличения – release (освобождение) или signal, уменьшения – acquire (захват) или wait.

На практике можно представить, что release – выделение квоты доступа к критической секции программы. acquire – использование необходимого объема доступной квоты, или ожидание, если её не хватает. Подробнее с деталями работы семафора поможет ознакомиться перевод статьи с картинками на хабре.

В Java семафор реализован классом Semaphore. Состоит этот класс в основном из разных форм методов acquire (с таймаутом, с игнорированием InterruptedException, неблокирующий) и release. Методы могут принимать параметр permits – тот самый объем квот, которые необходимо освободить/захватить.

Несколько вспомогательных методов позволяют узнать больше о количестве и составе очереди потоков, которые ждут освобождения пермитов. А методы availablePermits и drainPermits позволяют узнать количество оставшихся пермитов, и захватить их все соответственно. В конструкторе конфигурируются изначальное количество пермитов, и свойство fair (аналогичное свойству ReentrantLock).

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

@javatg
2024/10/04 21:12:36
Back to Top
HTML Embed Code: