Расчет хэша для каждой инструкции: Для RUN хэш включает точный текст команды (даже пробелы важны).
Для COPY/ADD — хэш файлов: Docker tar'ит (архивирует) контекст сборки (директорию с Dockerfile) и вычисляет checksum. Если файл изменился хоть на байт, хэш новый. В памяти хоста это происходит быстро: daemon использует минимум RAM, но для больших контекстов (много файлов) tar может занять время.
Использование кэша: Если хэш match, Docker копирует слой из /var/lib/docker/overlay2 (хранилище слоёв на диске). Нет выполнения команды — экономия времени и ресурсов. Если нет — создает временный контейнер, выполняет инструкцию и commit'ит новый слой.
Инвалидация цепочки: Вот ключевой момент — кэш цепной. Если слой N изменился, все слои ниже (N+1, N+2...) инвалидируются, даже если их инструкции не поменялись. Это потому, что каждый слой строится на предыдущем (union-файловая система).
В памяти и на диске: Кэш хранится локально, занимая диск (сотни МБ для образов). Нет загрузки в RAM до запуска контейнера. Но в CI/CD (системах непрерывной интеграции, как GitHub Actions) кэш может быть shared через registry — с BuildKit используйте --cache-to=type=inline или type=registry для экспорта.
Почему порядок инструкций так важен? Потому что он напрямую влияет на частоту инвалидации кэша.
Идея: ставьте стабильные, редко меняющиеся инструкции в начало, а изменяемые — в конец. Это минимизирует перестройки.
Пример плохого порядка (кэш часто ломается):
Хороший порядок (кэш работает эффективно):
Нюансы
В классическом билдере (до BuildKit) кэш линейный и последовательный. BuildKit (дефолт с Docker 18.09+, обязательно с 23.0) строит граф зависимостей: анализирует весь Dockerfile и выполняет независимые инструкции параллельно (на multi-core CPU). Например, несколько RUN без зависимостей — одновременно. Это ускоряет в 2-5 раз.
Флаги: --cache-from=remote для pull кэша из registry в CI; --cache-to=type=gha для GitHub Actions.
.dockerignore: Файл в корне, как .gitignore — исключает файлы из контекста (не tar'ятся). Например, игнор target/, node_modules — ускоряет build, снижает размер контекста (max 100-200 МБ, иначе ошибки).
"Застрявший" кэш: Если хэш неверный (баги, изменения env), используйте --no-cache в build — полная перестройка. Или docker builder prune — чистка кэша (освобождает диск).
Multi-platform и кэш: С Buildx (--platform linux/amd64,linux/arm64) кэш per-архитектура: отдельно для x86 и ARM. Эмуляция (QEMU) жрёт RAM (до 2x), но манифест объединяет.
Секреты и кэш: Пароли в RUN попадут в слой — используйте --secret для временного mount в память (tmpfs, не на диск).
Влияние на Java: Для Maven/Gradle deps кэшируются в слое, но в multi-stage — не в финале. Если deps большие (сотни МБ), оптимизируйте порядок для CI — сэкономите bandwidth.
В Docker Desktop (Mac/Windows) кэш медленнее из-за VM-layer; используйте mutagen или volume-sync для ускорения. Тестируйте: Соберите дважды — второй раз должен быть мгновенным, если ничего не изменилось.
#Java #middle #Docker #Dockerfile
Для COPY/ADD — хэш файлов: Docker tar'ит (архивирует) контекст сборки (директорию с Dockerfile) и вычисляет checksum. Если файл изменился хоть на байт, хэш новый. В памяти хоста это происходит быстро: daemon использует минимум RAM, но для больших контекстов (много файлов) tar может занять время.
Использование кэша: Если хэш match, Docker копирует слой из /var/lib/docker/overlay2 (хранилище слоёв на диске). Нет выполнения команды — экономия времени и ресурсов. Если нет — создает временный контейнер, выполняет инструкцию и commit'ит новый слой.
Инвалидация цепочки: Вот ключевой момент — кэш цепной. Если слой N изменился, все слои ниже (N+1, N+2...) инвалидируются, даже если их инструкции не поменялись. Это потому, что каждый слой строится на предыдущем (union-файловая система).
В памяти и на диске: Кэш хранится локально, занимая диск (сотни МБ для образов). Нет загрузки в RAM до запуска контейнера. Но в CI/CD (системах непрерывной интеграции, как GitHub Actions) кэш может быть shared через registry — с BuildKit используйте --cache-to=type=inline или type=registry для экспорта.
Почему порядок инструкций так важен? Потому что он напрямую влияет на частоту инвалидации кэша.
Идея: ставьте стабильные, редко меняющиеся инструкции в начало, а изменяемые — в конец. Это минимизирует перестройки.
Пример плохого порядка (кэш часто ломается):
textFROM eclipse-temurin:21-jre
COPY src /app/src # Код меняется часто — хэш новый каждый раз
RUN mvn clean package # Зависимости перестраиваются заново
COPY target/myapp.jar /app/myapp.jar
Здесь COPY src в начале — если код изменился (что бывает часто), RUN mvn ниже инвалидируется, и вся компиляция повторяется (минуты времени).
Хороший порядок (кэш работает эффективно):
textFROM eclipse-temurin:21-jre
COPY pom.xml /app # Только файл зависимостей — меняется редко
RUN mvn dependency:go-offline # Скачивает deps, кэшируется
COPY src /app/src # Код в конце — меняется, но deps уже в кэше
RUN mvn clean package
COPY target/myapp.jar /app/myapp.jar
Теперь, если код изменился, только последние RUN/COPY перестроятся — deps из кэша. Экономия: 80-90% времени на повторных билдах.
Нюансы
В классическом билдере (до BuildKit) кэш линейный и последовательный. BuildKit (дефолт с Docker 18.09+, обязательно с 23.0) строит граф зависимостей: анализирует весь Dockerfile и выполняет независимые инструкции параллельно (на multi-core CPU). Например, несколько RUN без зависимостей — одновременно. Это ускоряет в 2-5 раз.
Флаги: --cache-from=remote для pull кэша из registry в CI; --cache-to=type=gha для GitHub Actions.
.dockerignore: Файл в корне, как .gitignore — исключает файлы из контекста (не tar'ятся). Например, игнор target/, node_modules — ускоряет build, снижает размер контекста (max 100-200 МБ, иначе ошибки).
"Застрявший" кэш: Если хэш неверный (баги, изменения env), используйте --no-cache в build — полная перестройка. Или docker builder prune — чистка кэша (освобождает диск).
Multi-platform и кэш: С Buildx (--platform linux/amd64,linux/arm64) кэш per-архитектура: отдельно для x86 и ARM. Эмуляция (QEMU) жрёт RAM (до 2x), но манифест объединяет.
Секреты и кэш: Пароли в RUN попадут в слой — используйте --secret для временного mount в память (tmpfs, не на диск).
Влияние на Java: Для Maven/Gradle deps кэшируются в слое, но в multi-stage — не в финале. Если deps большие (сотни МБ), оптимизируйте порядок для CI — сэкономите bandwidth.
В Docker Desktop (Mac/Windows) кэш медленнее из-за VM-layer; используйте mutagen или volume-sync для ускорения. Тестируйте: Соберите дважды — второй раз должен быть мгновенным, если ничего не изменилось.
#Java #middle #Docker #Dockerfile
👍3
JVM в контейнере: настройки памяти и сборка мусора
JVM (виртуальная машина Java) в Docker требует специальной настройки, потому что контейнеры ограничивают ресурсы, и без адаптации приложение может крашнуться.
-Xmx и -XX:+UseContainerSupport: Флаг -Xmx задаёт максимальный размер кучи (heap — области для объектов Java), например, -Xmx512m.
Но в контейнере это опасно: если docker run --memory=1g, а -Xmx не задан или больше лимита, JVM возьмёт больше памяти, и система убьёт процесс (OOM-killer).
Флаг -XX:+UseContainerSupport (включен по умолчанию в Java 10 и выше) делает JVM "container-aware": она читает лимиты из cgroups (/sys/fs/cgroup/memory/memory.limit_in_bytes) и автоматически подстраивает heap под доступную память. В коде это видно через Runtime.getRuntime().maxMemory() — возвращает скорректированное значение (обычно 75% от лимита минус резервы JVM).
Не дублируйте -Xmx — используйте -XX:MaxRAMPercentage=80 для максимального процента от cgroup-лимита и -XX:InitialRAMPercentage=50 для стартового. Это позволяет динамически scaling в Kubernetes. Следите за native memory (память вне heap: нити, буферы, Metaspace для классов) — лимитируйте -XX:MaxMetaspaceSize=256m, иначе утечки съедят весь RAM. Включайте -XX:NativeMemoryTracking=detail для трекинга (overhead ~5%, но покажет breakdown).
В старых Java (8u131-) флаг не работает — обновляйтесь.
Сборка мусора в контейнерах: GC — процесс очистки кучи от "мусора" (ненужных объектов). В контейнере лимиты CPU и памяти влияют: низкая память — частые GC, низкий CPU — длинные паузы (app замирает). Выбор GC зависит от приложения.
G1GC (-XX:+UseG1GC, дефолт с Java 9): "Garbage-First" делит heap на регионы (по 1-32 МБ) и чистит "мусорные" первыми.
Плюсы: баланс между производительностью (throughput) и паузами (low-latency), подходит для heap 1-32 ГБ.
В контейнере: Учитывает cgroups — запускает GC раньше, минимизируя OOM. Паузы: 50-200 мс.
Настройте -XX:G1HeapRegionSize=2m для маленьких heap; -XX:ConcGCThreads=4 для CPU-квот. Если паузы высокие — мониторьте с -XX:+PrintGCDetails и JFR (Java Flight Recorder).
ZGC (-XX:+UseZGC, стабильный в Java 15+): Concurrent GC — чистит параллельно с app, паузы <10 мс даже на терабайтных heap.
Плюсы: Для high-throughput/low-pause apps (trading, streaming).
Минусы: Требует много CPU — при docker --cpus=2 throttling (замедление) растянет паузы.
В контейнере: Хорошо масштабируется, но тестируйте под load. В Java 21 — production-ready; -XX:ZCollectionInterval=5s для частоты; используйте для pause-sensitive микросервисов.
Shenandoah (-XX:+UseShenandoahGC): Похож на ZGC, но с evacuation (перемещением объектов) concurrently.
Плюсы: Лучше адаптируется к variable loads, низкие паузы.
Минусы: Меньше сообщества (Red Hat-driven).
В контейнере: Отлично для dynamic environments.
-XX:ShenandoahGCHeuristics=adaptive для auto-tune; комбинируйте с virtual threads (Java 21) для IO-bound apps.
Влияние cgroups: Runtime.maxMemory() = cgroup memory limit - JVM reserves (10-20%). При --cpus=0.5 GC использует меньше нитей (-XX:ParallelGCThreads auto-подстраивается).
Тестируйте: Запустите с -verbose:gc для логов; используйте JFR (-XX:StartFlightRecording) для профилей.
Нюанс: Virtual threads (Java 19+, stable 21) снижают overhead нитей (миллионы без OOM), но GC не меняется — они в heap. Для CPU-bound — ForkJoinPool лучше.
В production: Мониторьте с Prometheus JMX exporter.
#Java #middle #Docker #Dockerfile
JVM (виртуальная машина Java) в Docker требует специальной настройки, потому что контейнеры ограничивают ресурсы, и без адаптации приложение может крашнуться.
-Xmx и -XX:+UseContainerSupport: Флаг -Xmx задаёт максимальный размер кучи (heap — области для объектов Java), например, -Xmx512m.
Но в контейнере это опасно: если docker run --memory=1g, а -Xmx не задан или больше лимита, JVM возьмёт больше памяти, и система убьёт процесс (OOM-killer).
Флаг -XX:+UseContainerSupport (включен по умолчанию в Java 10 и выше) делает JVM "container-aware": она читает лимиты из cgroups (/sys/fs/cgroup/memory/memory.limit_in_bytes) и автоматически подстраивает heap под доступную память. В коде это видно через Runtime.getRuntime().maxMemory() — возвращает скорректированное значение (обычно 75% от лимита минус резервы JVM).
Не дублируйте -Xmx — используйте -XX:MaxRAMPercentage=80 для максимального процента от cgroup-лимита и -XX:InitialRAMPercentage=50 для стартового. Это позволяет динамически scaling в Kubernetes. Следите за native memory (память вне heap: нити, буферы, Metaspace для классов) — лимитируйте -XX:MaxMetaspaceSize=256m, иначе утечки съедят весь RAM. Включайте -XX:NativeMemoryTracking=detail для трекинга (overhead ~5%, но покажет breakdown).
В старых Java (8u131-) флаг не работает — обновляйтесь.
Сборка мусора в контейнерах: GC — процесс очистки кучи от "мусора" (ненужных объектов). В контейнере лимиты CPU и памяти влияют: низкая память — частые GC, низкий CPU — длинные паузы (app замирает). Выбор GC зависит от приложения.
G1GC (-XX:+UseG1GC, дефолт с Java 9): "Garbage-First" делит heap на регионы (по 1-32 МБ) и чистит "мусорные" первыми.
Плюсы: баланс между производительностью (throughput) и паузами (low-latency), подходит для heap 1-32 ГБ.
В контейнере: Учитывает cgroups — запускает GC раньше, минимизируя OOM. Паузы: 50-200 мс.
Настройте -XX:G1HeapRegionSize=2m для маленьких heap; -XX:ConcGCThreads=4 для CPU-квот. Если паузы высокие — мониторьте с -XX:+PrintGCDetails и JFR (Java Flight Recorder).
ZGC (-XX:+UseZGC, стабильный в Java 15+): Concurrent GC — чистит параллельно с app, паузы <10 мс даже на терабайтных heap.
Плюсы: Для high-throughput/low-pause apps (trading, streaming).
Минусы: Требует много CPU — при docker --cpus=2 throttling (замедление) растянет паузы.
В контейнере: Хорошо масштабируется, но тестируйте под load. В Java 21 — production-ready; -XX:ZCollectionInterval=5s для частоты; используйте для pause-sensitive микросервисов.
Shenandoah (-XX:+UseShenandoahGC): Похож на ZGC, но с evacuation (перемещением объектов) concurrently.
Плюсы: Лучше адаптируется к variable loads, низкие паузы.
Минусы: Меньше сообщества (Red Hat-driven).
В контейнере: Отлично для dynamic environments.
-XX:ShenandoahGCHeuristics=adaptive для auto-tune; комбинируйте с virtual threads (Java 21) для IO-bound apps.
Влияние cgroups: Runtime.maxMemory() = cgroup memory limit - JVM reserves (10-20%). При --cpus=0.5 GC использует меньше нитей (-XX:ParallelGCThreads auto-подстраивается).
Тестируйте: Запустите с -verbose:gc для логов; используйте JFR (-XX:StartFlightRecording) для профилей.
Нюанс: Virtual threads (Java 19+, stable 21) снижают overhead нитей (миллионы без OOM), но GC не меняется — они в heap. Для CPU-bound — ForkJoinPool лучше.
В production: Мониторьте с Prometheus JMX exporter.
#Java #middle #Docker #Dockerfile
👍3
Много ли у Вас друзей среди IT-шников?
Anonymous Poll
24%
Да! Есть как друзья детства, так и коллеги ставшие ими 🙂
7%
Да, но только коллеги, с кем сдружились 👋
24%
Есть много знакомых, из разных мест, но со всеми поддерживаю связь только по необходимости 🤷♀️
24%
Нет, я только начинаю свой путь в IT и пока не нашел друзей. 😉
21%
Нет, мне сложно заводить новые контакты. Предпочитаю удаленку и минимум общения 🤓
👍5
Что выведет код?
#Tasks
public class Task020925 {
private static int count = 0;
public static void main(String[] args) {
synchronized (Task020925.class) {
count++;
}
System.out.println(count);
}
}
#Tasks
👍2
👍4
Продолжаем выбирать темы для разбора и голосовать за рассмотрение предложенных! 🤓
Голосуем за тему к рассмотрению в эти выходные!
Выбираем новую тему!
(можете предложить что-то из того, что предлагали на прошлой и позапрошлых неделях и что проиграло в голосовании!)
Не стесняемся!✌️
Голосуем за тему к рассмотрению в эти выходные!
Выбираем новую тему!
(можете предложить что-то из того, что предлагали на прошлой и позапрошлых неделях и что проиграло в голосовании!)
Не стесняемся!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Вопрос с собеседований
Что такое parkNanos в LockSupport?🤓
Ответ:
LockSupport.parkNanos(long nanos) приостанавливает поток на указанное время в наносекундах.
Пример:
LockSupport.parkNanos(1_000_000_000); // 1 секунда
Более точный, чем sleep, но без InterruptedException.
#собеседование
Что такое parkNanos в LockSupport?
Ответ:
Пример:
LockSupport.parkNanos(1_000_000_000); // 1 секунда
Более точный, чем sleep, но без InterruptedException.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Андрей Николаевич Терехов (3 сентября 1949, Ленинград — 31 июля 2025) — советский и российский учёный в области информатики, доктор физико-математических наук, профессор, заведующий кафедрой системного программирования Санкт-Петербургского государственного университета.
1880 — в Петербурге инженер Фёдор Пироцкий продемонстрировал первый в России (по некоторым сведениям — первый в мире) электрический трамвай.
1976 — посадка космического аппарата Viking 2 на Марсе. NASA завершает посадку на Марс в рамках миссии Viking 2; зонд передал первые цветные снимки планеты.
1982 — начало фестиваля US Festival. Мероприятие, организуемое Стивом Возняком, сочетало музыку и технологические выставки (новейшие видеоигры, компьютерные демо), стало заметным культурно-техно событием.
#Biography #Birth_Date #Events #03Сентября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Основы ООП в Java
Глава 4. Полиморфизм
instanceof и приведение типов
В полиморфизме ссылка суперкласса или интерфейса может указывать на объект подкласса, но статический тип ссылки ограничивает доступ только к методам суперкласса. Чтобы получить доступ к методам подкласса или проверить тип, используются приведение типов и instanceof.
Приведение типов (Casting): Это преобразование ссылки одного типа в другой.
В Java:
Upcasting: Автоматическое приведение к суперклассу или интерфейсу (безопасно).
Downcasting: Явное приведение к подклассу (рискованно, может вызвать ошибку на runtime).
instanceof: Оператор, проверяющий на runtime, является ли объект экземпляром класса, подкласса или реализатором интерфейса. Возвращает boolean.
Это инструменты для безопасной работы с полиморфизмом: сначала проверка instanceof, затем downcasting.
Приведение типов: Upcasting и Downcasting
Upcasting: Автоматическое, безопасное. Ссылка подкласса преобразуется в суперкласс или интерфейс.
Почему: Для полиморфизма — общий код работает с разными объектами.
Нюанс: После upcasting доступны только методы суперкласса.
Пример:
Downcasting: Явное, с риском. Используйте (Type) перед ссылкой.
Почему: Чтобы получить доступ к методам подкласса через ссылку суперкласса.
Риск: Если объект не того типа — ClassCastException на runtime.
Пример:
Нюанс: Без проверки:
#Java #для_новичков #beginner #poliphormizm #instanceof #Upcasting #Downcasting
Глава 4. Полиморфизм
instanceof и приведение типов
В полиморфизме ссылка суперкласса или интерфейса может указывать на объект подкласса, но статический тип ссылки ограничивает доступ только к методам суперкласса. Чтобы получить доступ к методам подкласса или проверить тип, используются приведение типов и instanceof.
Приведение типов (Casting): Это преобразование ссылки одного типа в другой.
В Java:
Upcasting: Автоматическое приведение к суперклассу или интерфейсу (безопасно).
Downcasting: Явное приведение к подклассу (рискованно, может вызвать ошибку на runtime).
instanceof: Оператор, проверяющий на runtime, является ли объект экземпляром класса, подкласса или реализатором интерфейса. Возвращает boolean.
Это инструменты для безопасной работы с полиморфизмом: сначала проверка instanceof, затем downcasting.
Приведение типов: Upcasting и Downcasting
Upcasting: Автоматическое, безопасное. Ссылка подкласса преобразуется в суперкласс или интерфейс.
Почему: Для полиморфизма — общий код работает с разными объектами.
Нюанс: После upcasting доступны только методы суперкласса.
Пример:
Dog dog = new Dog("Шарик");
Animal animal = dog; // Upcasting: Dog → Animal (автоматически)
animal.makeSound(); // Вызывает версию Dog (полиморфизм)
Здесь animal — тип Animal, но объект Dog.
Downcasting: Явное, с риском. Используйте (Type) перед ссылкой.
Почему: Чтобы получить доступ к методам подкласса через ссылку суперкласса.
Риск: Если объект не того типа — ClassCastException на runtime.
Пример:
Animal animal = new Dog("Шарик"); // Upcasting
Dog dog = (Dog) animal; // Downcasting: Animal → Dog
dog.bark(); // Доступен метод Dog
Работает, потому что объект действительно Dog.
Нюанс: Без проверки:
Animal animal = new Cat("Мурка");
Dog dog = (Dog) animal; // ClassCastException: Cat cannot be cast to Dog
#Java #для_новичков #beginner #poliphormizm #instanceof #Upcasting #Downcasting
👍5
Оператор instanceof: Проверка типа
instanceof проверяет совместимость типов на runtime.
Синтаксис:
Нюанс: Для null — всегда false.
С Java 14+: Pattern matching (instanceof с переменной), но для простоты используем классический.
Пример безопасного downcasting:
С интерфейсами:
Нюансы instanceof:
Работает с классами, интерфейсами, массивами.
Для примитивов — нет (они не объекты).
В иерархии: Dog instanceof Animal — true; Animal instanceof Dog — false (если объект Animal).
Performance: Не дорогой, но избегайте в горячих циклах.
Альтернативы: getClass().equals(Class.class) — строже, не учитывает подтипы.
Полный пример с полиморфизмом
Используем Animal, Dog, Cat:
Нюансы
ClassCastException: Всегда проверяйте instanceof перед downcasting.
Null: null instanceof Type — false; (Type) null — null (без исключения).
Generics: instanceof не работает с параметризованными типами на runtime (type erasure).
Массивы: Object[] instanceof String[] — false, даже если элементы String.
Интерфейсы: Класс может реализовывать несколько — instanceof true для любого.
Final классы: Не влияет на instanceof.
Performance и дизайн: Избегайте чрезмерного использования instanceof — это признак плохого дизайна (лучше полиморфизм через overriding). Используйте, когда нужно специфическое поведение.
Java 14+ Pattern Matching: if (animal instanceof Dog d) { d.bark(); } — упрощает, но для совместимости используйте классику.
Как создать это в IntelliJ IDEA
Проверка instanceof: IDE подскажет автодополнение.
Генерация: После if (a instanceof Dog) { } — IDE предложит создать переменную.
Debug: Поставьте breakpoint и смотрите типы объектов.
Полезные советы для новичков
Всегда проверяйте перед cast: Избегайте runtime ошибок.
Предпочитайте overriding: Вместо instanceof + cast, переопределяйте методы.
В коллекциях: Полезно для фильтрации типов.
#Java #для_новичков #beginner #poliphormizm #instanceof #Upcasting #Downcasting
instanceof проверяет совместимость типов на runtime.
Синтаксис:
object instanceof Type
Возвращает true, если объект является экземпляром Type (класс, интерфейс) или его подтипа.
Нюанс: Для null — всегда false.
С Java 14+: Pattern matching (instanceof с переменной), но для простоты используем классический.
Пример безопасного downcasting:
Animal animal = new Dog("Шарик");
if (animal instanceof Dog) {
Dog dog = (Dog) animal;
dog.bark(); // Безопасно
} else {
System.out.println("Не собака!");
}
Проверка предотвращает ClassCastException.
С интерфейсами:
SoundMaker sound = new Dog("Шарик");
if (sound instanceof SoundMaker) { // true
// ...
}
Нюансы instanceof:
Работает с классами, интерфейсами, массивами.
Для примитивов — нет (они не объекты).
В иерархии: Dog instanceof Animal — true; Animal instanceof Dog — false (если объект Animal).
Performance: Не дорогой, но избегайте в горячих циклах.
Альтернативы: getClass().equals(Class.class) — строже, не учитывает подтипы.
Полный пример с полиморфизмом
Используем Animal, Dog, Cat:
public class Main {
public static void main(String[] args) {
Animal[] animals = {new Dog("Шарик"), new Cat("Мурка"), new Animal("Зверь")};
for (Animal a : animals) {
a.makeSound(); // Полиморфизм: каждый свой звук
if (a instanceof Dog) {
Dog d = (Dog) a;
d.bark(); // Только для Dog
} else if (a instanceof Cat) {
Cat c = (Cat) a;
// Специфический метод Cat, если есть
}
}
}
}
Цикл работает с массивом Animal, но проверяет и приводит для специфического поведения.
Нюансы
ClassCastException: Всегда проверяйте instanceof перед downcasting.
Null: null instanceof Type — false; (Type) null — null (без исключения).
Generics: instanceof не работает с параметризованными типами на runtime (type erasure).
Массивы: Object[] instanceof String[] — false, даже если элементы String.
Интерфейсы: Класс может реализовывать несколько — instanceof true для любого.
Final классы: Не влияет на instanceof.
Performance и дизайн: Избегайте чрезмерного использования instanceof — это признак плохого дизайна (лучше полиморфизм через overriding). Используйте, когда нужно специфическое поведение.
Java 14+ Pattern Matching: if (animal instanceof Dog d) { d.bark(); } — упрощает, но для совместимости используйте классику.
Как создать это в IntelliJ IDEA
Проверка instanceof: IDE подскажет автодополнение.
Генерация: После if (a instanceof Dog) { } — IDE предложит создать переменную.
Debug: Поставьте breakpoint и смотрите типы объектов.
Полезные советы для новичков
Всегда проверяйте перед cast: Избегайте runtime ошибок.
Предпочитайте overriding: Вместо instanceof + cast, переопределяйте методы.
В коллекциях: Полезно для фильтрации типов.
#Java #для_новичков #beginner #poliphormizm #instanceof #Upcasting #Downcasting
👍3
А вы были за границей, на отдыхе или по делам?
Anonymous Poll
15%
Да! Я регулярно летаю отдыхать в разные страны мира ✈️
36%
Да, но один или несколько раз. Хочу еще 😭
9%
Не скажу. Это секрет 🤫
27%
Нет, не позволяют финансы, но очень хочу...☺️
12%
Нет и мне не интересно! В России достаточно мест для отдыха 🙂
🔥2
Что выведет код?
#Tasks
public class Task030925 {
public static void main(String[] args) {
Object obj = "Hello";
if (obj instanceof Integer) {
Integer num = (Integer) obj;
System.out.println(num + 10);
} else if (obj instanceof String str) {
System.out.println(str.length());
} else {
System.out.println("Unknown");
}
}
}
#Tasks
👍1
👍1
Вопрос с собеседований
Что такое WatchService в Java?🤓
Ответ:
WatchService (java.nio.file) мониторит изменения в файловой системе.
Пример:
WatchService watcher = FileSystems.getDefault().newWatchService();
Path dir = Paths.get(".");
dir.register(watcher, StandardWatchEventKinds.ENTRY_CREATE);
WatchKey key = watcher.take();
Полезен для файловых наблюдателей.
#собеседование
Что такое WatchService в Java?
Ответ:
Пример:
WatchService watcher = FileSystems.getDefault().newWatchService();
Path dir = Paths.get(".");
dir.register(watcher, StandardWatchEventKinds.ENTRY_CREATE);
WatchKey key = watcher.take();
Полезен для файловых наблюдателей.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Джон Маккарти (англ. John McCarthy; 4 сентября 1927, Бостон — 24 октября 2011, Стэнфорд) — американский информатик, автор термина «искусственный интеллект» (1956), изобретатель языка Лисп (1958), основоположник функционального программирования, лауреат премии Тьюринга (1971) за огромный вклад в область исследований искусственного интеллекта.
Карле́н Ара́мович Абгаря́н (4 сентября 1928, Амасия, Ленинаканский уезд — 4 февраля 1995, Санкт-Петербург) — советский учёный в области технической кибернетики/автоматизации и робототехники.
1837 — в Нью-Йоркском университете Сэмюэл Морзе впервые продемонстрировал своё изобретение — телеграф.
1882 — в Нью-Йорке Томас Эдисон запустил первую в мире центральную электростанцию и впервые в истории включил коммерческое электрическое освещение (всего для 85 платных клиентов).
1964 — в Шотландии официально открыт Форт-Роуд-Бридж.
1998 — официальное учреждение (регистрация/основание) Google. Ключевая веха истории поисковых систем и дальнейшего развития веб-экосистемы.
#Biography #Birth_Date #Events #04Сентября
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Основы ООП в Java
Глава 5. Абстракция
Абстрактные классы и методы
Абстракция — это принцип ООП, который упрощает сложные системы, скрывая ненужные детали и показывая только essential интерфейс. Это позволяет моделировать реальные концепции на высоком уровне: например, "автомобиль" как абстракция, где вы знаете, что он едет, но не вникаете в механику двигателя.
В Java абстракция реализуется через абстрактные классы и интерфейсы (интерфейсы подробнее в следующем уроке). Абстрактные классы предоставляют частичную реализацию, заставляя подклассы заполнить пробелы.
Абстрактные классы: Определение и использование
Абстрактный класс — это класс, помеченный ключевым словом abstract, который нельзя инстанцировать (new AbstractClass() — ошибка). Он служит шаблоном для подклассов, предоставляя общий код и требуя реализации специфических частей.
Синтаксис:
Особенности:
Может иметь абстрактные методы (без тела).
Может иметь обычные (concrete) методы с реализацией.
Может иметь поля, конструкторы.
Подклассы должны extends абстрактный класс и реализовать все абстрактные методы (или сами стать abstract).
Нюанс: Абстрактный класс может не иметь абстрактных методов — просто для предотвращения инстанциации.
Пример абстрактного класса Shape (Фигура):
#Java #для_новичков #beginner #Abstract
Глава 5. Абстракция
Абстрактные классы и методы
Абстракция — это принцип ООП, который упрощает сложные системы, скрывая ненужные детали и показывая только essential интерфейс. Это позволяет моделировать реальные концепции на высоком уровне: например, "автомобиль" как абстракция, где вы знаете, что он едет, но не вникаете в механику двигателя.
В Java абстракция реализуется через абстрактные классы и интерфейсы (интерфейсы подробнее в следующем уроке). Абстрактные классы предоставляют частичную реализацию, заставляя подклассы заполнить пробелы.
Абстрактные классы: Определение и использование
Абстрактный класс — это класс, помеченный ключевым словом abstract, который нельзя инстанцировать (new AbstractClass() — ошибка). Он служит шаблоном для подклассов, предоставляя общий код и требуя реализации специфических частей.
Синтаксис:
public abstract class AbstractClass {
// Абстрактные методы, concrete методы, поля
}
Особенности:
Может иметь абстрактные методы (без тела).
Может иметь обычные (concrete) методы с реализацией.
Может иметь поля, конструкторы.
Подклассы должны extends абстрактный класс и реализовать все абстрактные методы (или сами стать abstract).
Нюанс: Абстрактный класс может не иметь абстрактных методов — просто для предотвращения инстанциации.
Пример абстрактного класса Shape (Фигура):
public abstract class Shape {
protected String color; // Общее поле
public Shape(String color) {
this.color = color;
}
// Абстрактный метод: Подклассы должны реализовать
public abstract double getArea();
// Concrete метод: Общий для всех
public void displayColor() {
System.out.println("Цвет: " + color);
}
}
getArea(): Абстрактный — без тела, заканчивается ;.
displayColor(): С реализацией — наследуется как есть.
#Java #для_новичков #beginner #Abstract
👍4
Абстрактные методы: Требование реализации
Абстрактный метод — это метод без тела, помеченный abstract. Он определяет "что делать", но не "как".
Синтаксис:
Правила:
Может быть только в абстрактном классе или интерфейсе.
Нет тела — только сигнатура.
Подклассы должны override и реализовать (или стать abstract).
Модификаторы: Не может быть private (бесполезно, если не виден), final (нельзя override), static (static не override).
Подкласс Circle, реализующий Shape:
Полиморфизм с абстрактными классами
Абстрактные классы усиливают полиморфизм: ссылка на абстрактный класс может указывать на concrete подклассы.
Пример:
Все нюансы абстрактных классов и методов
Инстанциация: new AbstractClass() — ошибка компиляции.
Конструкторы: Могут быть, вызываются super() из подклассов. Полезны для инициализации общих полей.
Поля: Могут быть final, static, private и т.д. Static поля/методы доступны через AbstractClass.field.
Наследование: Абстрактный класс может extends другой abstract или concrete класс.
Интерфейсы vs abstract классы: Abstract классы могут иметь реализацию и состояние; интерфейсы — нет (до Java 8). Abstract для "is-a" с частичной реализацией.
Ошибки:
Абстрактный метод в non-abstract классе — ошибка.
Не реализован abstract метод в concrete подклассе — ошибка.
Abstract метод с телом — ошибка.
Модификаторы: Abstract класс не может быть final (final не extends). Abstract метод не может быть final/static/private.
Дизайн: Используйте для шаблонов с общим кодом, где подклассы уточняют поведение. Избегайте глубоких иерархий.
Java-специфика: С Java 8 интерфейсы имеют default методы, размывая грань с abstract классами.
Как создать это в IntelliJ IDEA
Абстрактный класс: New → Java Class → Укажите abstract в коде, или IDE предложит.
Абстрактный метод: В abstract классе напишите abstract void method(); — IDE подскажет.
Реализация: В подклассе Ctrl+O (Override) — выберите abstract метод.
Проверка: Если не реализован — IDE выделит ошибку.
Полезные советы для новичков
Используйте abstract для контрактов: Заставьте подклассы реализовать ключевые методы.
Конструкторы в abstract: Полезны для общих init.
Комбинируйте с полиморфизмом: Ссылки на abstract класс для коллекций подклассов.
Избегайте: Не делайте все abstract — используйте concrete для общего.
Ресурсы: Oracle Tutorials on Abstract Classes.
#Java #для_новичков #beginner #Abstract
Абстрактный метод — это метод без тела, помеченный abstract. Он определяет "что делать", но не "как".
Синтаксис:
public abstract returnType methodName(params);
Правила:
Может быть только в абстрактном классе или интерфейсе.
Нет тела — только сигнатура.
Подклассы должны override и реализовать (или стать abstract).
Модификаторы: Не может быть private (бесполезно, если не виден), final (нельзя override), static (static не override).
Подкласс Circle, реализующий Shape:
public class Circle extends Shape {
private double radius;
public Circle(String color, double radius) {
super(color); // Вызов конструктора абстрактного класса
this.radius = radius;
}
// Реализация абстрактного метода
@Override
public double getArea() {
return Math.PI * radius * radius;
}
}
Circle не abstract, так что обязан реализовать getArea().
Теперь можно new Circle(...), но не new Shape().
Полиморфизм с абстрактными классами
Абстрактные классы усиливают полиморфизм: ссылка на абстрактный класс может указывать на concrete подклассы.
Пример:
public class Main {
public static void main(String[] args) {
Shape shape = new Circle("Красный", 5.0); // Полиморфизм: Shape на Circle
shape.displayColor(); // Цвет: Красный (concrete метод)
System.out.println("Площадь: " + shape.getArea()); // Площадь: ~78.54 (реализация Circle)
}
}
Нюанс: Конструктор абстрактного класса вызывается через super(), даже если класс abstract.
Все нюансы абстрактных классов и методов
Инстанциация: new AbstractClass() — ошибка компиляции.
Конструкторы: Могут быть, вызываются super() из подклассов. Полезны для инициализации общих полей.
Поля: Могут быть final, static, private и т.д. Static поля/методы доступны через AbstractClass.field.
Наследование: Абстрактный класс может extends другой abstract или concrete класс.
Интерфейсы vs abstract классы: Abstract классы могут иметь реализацию и состояние; интерфейсы — нет (до Java 8). Abstract для "is-a" с частичной реализацией.
Ошибки:
Абстрактный метод в non-abstract классе — ошибка.
Не реализован abstract метод в concrete подклассе — ошибка.
Abstract метод с телом — ошибка.
Модификаторы: Abstract класс не может быть final (final не extends). Abstract метод не может быть final/static/private.
Дизайн: Используйте для шаблонов с общим кодом, где подклассы уточняют поведение. Избегайте глубоких иерархий.
Java-специфика: С Java 8 интерфейсы имеют default методы, размывая грань с abstract классами.
Как создать это в IntelliJ IDEA
Абстрактный класс: New → Java Class → Укажите abstract в коде, или IDE предложит.
Абстрактный метод: В abstract классе напишите abstract void method(); — IDE подскажет.
Реализация: В подклассе Ctrl+O (Override) — выберите abstract метод.
Проверка: Если не реализован — IDE выделит ошибку.
Полезные советы для новичков
Используйте abstract для контрактов: Заставьте подклассы реализовать ключевые методы.
Конструкторы в abstract: Полезны для общих init.
Комбинируйте с полиморфизмом: Ссылки на abstract класс для коллекций подклассов.
Избегайте: Не делайте все abstract — используйте concrete для общего.
Ресурсы: Oracle Tutorials on Abstract Classes.
#Java #для_новичков #beginner #Abstract
👍4
Что для Вас важнее: чистый и читаемый или быстрый и функциональный код?
Anonymous Poll
31%
Чистота кода самое важное! Удобно читать - удобно поддерживать! 🧼
9%
Читаемый код по-любому работает хорошо! ✌️
54%
Все эти принципы одинаково нужны и важны! 👌
3%
Быстрый код важнее! Кому нужно он прочтет 🤷♀️
3%
Самое важное чтобы код делал что ему положено бизнес-логикой. Остальное не важно 💃
👍1
Что выведет код?
#Tasks
public class Task040925 {
public static void main(String[] args) {
String s1 = "Java";
String s2 = new String("Java");
String s3 = s2.intern();
String s4 = new StringBuilder("Ja").append("va").toString();
String s5 = s4.intern();
System.out.println((s1 == s3) + " " + (s1 == s5) + " " + (s4 == s5));
}
}
#Tasks
👍2