Java | Фишки и трюки

Не трогайте, это на Новый год! Профессия «Java-разработчик» 🎁 🎊 Получите скидку до 30 000 р. и кэшбек на карту до 25 000 р. при успешном прохождении обучения! Освойте язык крупного бизнеса и финансовых технологий и научитесь разрабатывать веб-приложения на фреймворке Spring. Уже во время обучения вы вступите в программу «Карьерный трек», чтобы найти свою первую работу в IT.  Вы научитесь подбирать правильные структуры для хранения и обработки данных, познакомитесь с автоматизированным тестированием и напишите свои первые модульные тесты. 📌 Пройдите 5 бесплатных уроков и поймите, подходит ли вам профессия! Реклама. АНПОО "ХЕКСЛЕТ КОЛЛЕДЖ". ИНН 7839056670.

JIT-компилятор На начальном этапе выполнения программы байт-код интерпретируется JVM. Это позволяет быстро запускать программы без необходимости предварительной компиляции в машинный код. JIT-компилятор является ключевым элементом виртуальной машины Java (JVM). Он компилирует байт-код часто вызываемых методов в машинный код во время выполнения. Следовательно, он отвечает за оптимизацию программ Java. JVM автоматически отслеживает, какие методы выполняются. Как только метод становится пригодным для JIT-компиляции, его планируется компилировать в машинный код. Этот метод так же известен как горячий метод. Эта компиляция в машинный код происходит в отдельном потоке JVM. В результате он не прерывает выполнение текущей программы. После компиляции в машинный код, метод работает быстрее. Таким образом, JIT-компиляция в Java позволяет достичь компромисса между портативностью байт-кода и производительностью машинного кода. Этот механизм позволяет Java-приложениям быть эффективными на различных платформах, так как байт-код может быть выполнен на любой машине, в то время как JIT-компиляция обеспечивает высокую производительность приложений в процессе их выполнения.

⌨️ Управление доступом к членам класса Модификаторы уровня доступа определяют, могут ли другие классы использовать определенное поле или вызывать определенный метод. Существует 4 уровня доступа: private Указывает, что доступ к члену возможен только в его собственном классе. package-private (нет явного модификатора) Указывает, что доступ к члену только внутри своего собственного пакета. protected Указывает, что доступ к члену возможен только внутри его собственного пакета (как в случае с package-private) и, кроме того, для подкласса его класса в другом пакете. public Указывает, что доступ к члену возможен отовсюду.

Как быстро собрать такую форму оплаты? Легко! Фронтенд гайд, это канал для верстальщиков, в котором публикуют: ✓ Готовый код ✓ Макеты для верстки ✓ Тесты на знание кода Ускорь работу над своим проектом!

Тысячи слитых книг по разработке и дизайну! Книжки айтишки - хранилище лучших книг, здесь вы скачаете всё абсолютно бесплатно! HTML - (121 книга); CSS - (98 книг); Python - (301 книга); Java - (137 книг); JavaScript - (302 книги); Figma - (76 книг); Unity - (56 книг); И много других Успей подписаться, ссылка действует 24ч!

SOLID — принципы объектно‑ориентированного программирования SOLID — это аббревиатура пяти основных принципов проектирования в объектно‑ориентированном программировании — Single responsibility, Open-closed, Liskov substitution, Interface segregation и Dependency inversion. В переводе на русский: принципы единственной ответственности, открытости / закрытости, подстановки Барбары Лисков, разделения интерфейса и инверсии зависимостей. Аббревиатура SOLID была предложена Робертом Мартином, автором нескольких книг, широко известным в сообществе разработчиков. Следование принципам позволяет строить на базе ООП масштабируемые и сопровождаемые программные продукты с понятной бизнес‑логикой. Код, который написан с соблюдением принципов SOLID, проще понимать, поддерживать, расширять или изменять его функциональность. Принцип единственной обязанности / ответственности (single responsibility principle / SRP) обозначает, что каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулирована в класс. Все его сервисы должны быть направлены исключительно на обеспечение этой обязанности. Принцип открытости / закрытости (open-closed principle / OCP) декларирует, что программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения. Это означает, что эти сущности могут менять свое поведение без изменения их исходного кода. Принцип подстановки Барбары Лисков (Liskov substitution principle / LSP) в формулировке Роберта Мартина: «функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа не зная об этом». Принцип разделения интерфейса (interface segregation principle / ISP) в формулировке Роберта Мартина: «клиенты не должны зависеть от методов, которые они не используют». Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы необходимо разделять на более маленькие и специфические, чтобы клиенты маленьких интерфейсов знали только о методах, которые необходимы им в работе. В итоге, при изменении метода интерфейса не должны меняться клиенты, которые этот метод не используют. Принцип инверсии зависимостей (dependency inversion principle / DIP) — модули верхних уровней не должны зависеть от модулей нижних уровней, а оба типа модулей должны зависеть от абстракций; сами абстракции не должны зависеть от деталей, а вот детали должны зависеть от абстракций.

⚡ Когда мне говорят, что Java слишком простой язык, я показываю канал Java Learning Здесь я научился: ▪️ Разрабатывать высоконагруженные серверные приложения ▪️ Управлять сложными базами данных ▪️ Организовывать эффективную многопоточную обработку данных ▪️ Проходить технические собеседования в ведущие IT-компании Самый необычный канал про Java, подписывайся – @Java_per_month

PrintStream является классом, предназначенным для удобного вывода различных типов данных в поток вывода. Он является подклассом OutputStream и предоставляет методы для вывода данных различных примитивных типов, строк и объектов в удобном для чтения текстовом формате. В этом примере PrintStream используется для вывода данных как в консоль, так и в файл. Он обеспечивает удобный способ форматирования и вывода данных различных типов. Класс PrintStream также автоматически преобразует различные типы данных в их текстовое представление перед выводом.

Java Developer — мастхев для любого джависта За ручку проведём тебя к первому офферу, расскажем о сложных вещах простыми словами и научим смеяться с айтишных мемов. ➡️ Подписывайся и прокачивай свои навыки

Проблема N+1 (N+1 Issue) в JPA (Java Persistence API) возникает, когда при получении списка сущностей с их связанными сущностями (например, при использовании отношения OneToMany или ManyToOne), для каждой основной сущности выполняется дополнительный запрос для загрузки связанной сущности. Это приводит к выполнению N+1 запросов к базе данных, где N - количество основных сущностей. В нашем примере, даже если авторы были извлечены одним запросом, при обращении к каждому списку книг (author.getBooks()) будет выполнен дополнительный запрос для каждого автора, что может привести к большому количеству запросов и снижению производительности. Использование управления загрузкой, такого как JOIN FETCH или использование JPA Entity Graphs, позволяет предотвратить проблему N+1 и повысить производительность при работе с базой данных через JPA.

Чем отличаются эти два способа определения массива?

int[] array = new int[]{1,2,3}
int[] array = {1,2,3}

Ответ: ничем не отличается, эти два определения идентичны на уровне байт-кода.

JPA Entity Graph - это механизм, предоставляемый JPA, который позволяет явно указывать, какие атрибуты сущности должны быть загружены или проигнорированы во время выполнения запросов к базе данных. Это может быть полезно для управления жадной загрузкой (eager loading) и ленивой загрузкой (lazy loading) связанных сущностей. JPA Entity Graph предоставляет более гибкий и декларативный способ управления загрузкой связанных данных по сравнению с использованием параметра fetch в аннотациях связи с другими сущностями. Он также позволяет избежать проблем с N+1 запросами, когда множество связанных сущностей загружается в отдельных запросах. В нашем примере мы создали именованный граф сущности (person-with-address), который включает атрибуты name из сущности Person и также включает атрибут address с дополнительным подграфом (address-subgraph), который включает атрибут city из сущности Address. Далее мы используем getEntityGraph для получения ссылки на ранее созданный граф сущности, а затем передаем его в запрос find с использованием соответствующих свойств. Это позволяет загрузить только указанные атрибуты, что может быть полезно для оптимизации производительности и избежания избыточной загрузки данных. Entity Graph можно так же создавать динамически используя метод createEntityGraph вместо getEntityGraph.

Параметр fetch в аннотациях @ManyToOne, @ManyToMany, @OneToOne, @OneToMany определяет как будет загружаться связанная сущность: вместе с загрузкой родительской сущности или в момент обращения к аннотированному полю. Этот параметр может принимать два значения: EAGER: при загрузке родительской сущности будет загружена и дочерняя сущность. Это один SQL-запрос с выбором родительской сущности к которой присоединяется (LEFT JOIN) дочерняя. LAZY: при загрузке родительской сущности, дочерняя сущность загружена не будет. Вместо нее будет создан proxy-объект. С помощью этого proxy-объекта Hibernate будет отслеживать обращение к этой дочерней сущности и при первом обращении загрузит ее в память. Какой же использовать? Если сущности не большие и связей не много, а проект не сильно нагруженный, то можно использовать EAGER, иначе нагрузка на БД может быть большой и в результате приложение может стать задумчивым. Но LAZY не панацея, например мы можем выбрать список сущностей и что то с ними делать в цикле обращаясь к полю LAZY, в результате мы получим дополнительный запрос на каждый элемент списка, что так же увеличит нагрузку на БД. В данном случае нужно выбрать это поле как EAGER. Получается что у нас могут быть разные варианты использования выбранной сущности. Как же быть? Первое что приходит в голову это сделать набор сущностей которые смотрят на одну и ту же таблицу, но в которых параметр fetch задан по разному, в зависимости от использования сущности. Но такой способ выглядит криво: дублирование кода, проблемы с передачей сущности в методы (классы сущностей все разные). В следующих постах поговорим о том как этого избежать. Не переключайте канал.

Память кучи В Java память кучи (heap memory) является областью памяти, где хранятся объекты и массивы. Куча управляется сборщиком мусора (garbage collector), который автоматически освобождает память, занятую объектами, которые больше не используются. Динамическое выделение Объекты в Java создаются динамически во время выполнения программы. Куча предоставляет пространство для хранения этих объектов, и их размер может изменяться в процессе выполнения программы. Управление сборкой мусора Java-программисты не обязаны явно освобождать память после использования объектов. Сборщик мусора автоматически отслеживает объекты, на которые больше нет ссылок, и освобождает память, которую они занимали. Это позволяет избежать утечек памяти. Поколения кучи Память кучи в Java обычно делится на три поколения: молодое поколение (young generation), поколение средней жизни (tenured/old generation) и поколение постоянных объектов (permanent generation, до Java 7) или область метаспейса (metaspace, начиная с Java 8). 👉 Молодое поколение содержит новые объекты, которые создаются в программе. Сборка мусора часто выполняется в этом поколении. 👉 Поколение средней жизни содержит объекты, которые пережили несколько циклов сборки мусора в молодом поколении. 👉 Поколение постоянных объектов (или область метаспейса) содержит метаданные классов и постоянные строки. В Java 8 и более поздних версиях используется метаспейс вместо постоянного поколения. Настройка кучи Размеры и параметры работы сборщика мусора и памяти кучи можно настраивать с использованием опций командной строки при запуске Java-приложения. Например, можно указать максимальный и начальный размеры кучи, выбрать алгоритм сборки мусора и другие параметры. Производительность и оптимизации Память кучи и сборка мусора в Java подвергаются постоянным оптимизациям и улучшениям в новых версиях JDK. Производительность приложений может зависеть от эффективности работы сборщика мусора и правильного управления памятью.