Java: fill the gaps

Виды многозадачности Сегодня выйдем за пределы JVM и посмотрим на многопоточность на уровне ОС. Многопоточность — когда в одном процессе параллельно работают несколько потоков. Многозадачность — несколько процессов параллельно исполняются в ОС. При этом параллельно — не значит одновременно. Процесс/поток использует ресурсы процессора некоторое время, потом выполнение прерывается, ОС сохраняет временные данные (контекст), а ресурсы переходят на другой процесс/поток. Загружается контекст другой задачи, и выполнение продолжается. Многозадачность бывает двух типов: 1. Вытесняющая. ОС выделяет кванты времени для каждой задачи и управляет их переключением. Так работают потоки в джаве, а также процессы в современных ОС. ✅ не нужно думать о переключении задач, всё делает ОС ✅ повисшая задача не блокирует остальные ❌ сложная работа с общими ресурсами ❌сложно координировать связанные параллельные задачи 2. Кооперативная. Программа/поток сами сигнализируют, что пора сохранить контекст и переключиться на другую задачу. Так были организованы ОС давным-давно. В прикладных программах эта модель реализуется через fibers – «легковесные потоки», которые исполняются на одном потоке ОС и имеют собственный планировщик. ✅ переключение контекста происходит в 10-100 раз быстрее ✅ проще работа с общими ресурсами, не нужно часто синхронизироваться ✅ эффективная обработка некоторого типа задач ❌ увеличенная сложность разработки ❌ ошибка в одной задаче сильно влияет на другие, вплоть до остановки основного процесса По умолчанию для java программ используется вытесняющая многозадачность. Однако преимущества кооперативной модели можно получить с помощью некоторых библиотек или конструкций из котлина. #fillthegaps_mt #java #multitasking #fibers #preemptive #cooperative

Бесполезная калибровка Thread.sleep или как JDK создаёт иллюзию выбора. Все знают метод sleep(long millis) у класса Thread. Он останавливает выполнение потока на заданное количество миллисекунд. Также в классе есть похожий метод sleep(long millis, int nanos). Здравый смысл подсказывает, что это тот же sleep, только время приостановки задаётся точнее. Документация к методу подтверждает нашу догадку: ...sleep for the specified number of milliseconds plus the specified number of nanoseconds. Что тут ещё обсуждать? Расходимся! Но всё же посмотрим в код. После проверок на валидность, видим следующие строки: if (nanos >= 500000 || (nanos != 0 && millis == 0)) { millis++; } sleep(millis); То есть прибавить 1 миллисекунду, если наносекунд больше 500к. Или выставить паузу в 1 миллисекунду, если микросекунд 0, а наносекунд не 0. У JVM доступен один нативный метод, который работает только с миллисекундами. Поэтому результат не очень удивляет. Но зачем тогда нужен второй метод? #core

Нужно ли разбираться в многопоточке если на проекте она используется на базовом уровне? Ответ простой: надо. Это базовая часть функционала JDK. Если этого мало, вот ещё причины углубить знания: 1. Заодно изучаешь более сложные алгоритмы и структуры данных, организацию JVM и ещё много интересного. Эта тема - самая близкая к реальным проблемам область языка. 2. Видишь проблемы в коде, которые невозможно поймать на тестировании, но которые обязательно проявятся на продакшене. 3. Увидишь, как оптимизировать ресурсы и ускорить работу системы. 4. Серьёзно увеличиваешь свой рейтинг в коллективе и на собеседованиях Многопоточное программирование — тесная связь теории и практики. Если ты иногда читаешь статьи по теме, то ты не станешь мастером многопоточки, здесь нужен основательный подход. Большинство видео на youtube, курсов и статей дают поверхностный обзор инструментов, основываются на java 7 и устарели. В них много воды и мало практики. Я потратила много времени на изучение многопоточности. Читала сотни статей лучших экспертов, разбиралась в исходниках JDK, применяла на своих проектах и смотрела кейсы других компаний. Изучение и сравнение инструментов порождает много вопросов. Когда использовать одно, а когда другое? Это действительно влияет на производительность, или разница не так велика, чтобы тратить усилия? Сейчас я работаю над полным и актуальным курсом по многопоточности в java 13. От основ до тонкостей использования. Этот курс поможет разобраться в теме , эффективно применять свои знания и, самое главное, серьёзно сэкономит ваше время. Планирую закончить курс уже в следующем месяце, stay tuned. #fillthegaps_mt #multithreading #learning #fillthegaps_course

​Как удалить элементы из коллекции? Допустим, мы хотим удалить устаревшие или неправильные значения из коллекции. Если менять коллекцию во время обхода, то результаты будут неоднозначны, поэтому в JDK в таком случае бросается ConcurrentModificationException. Популярный способ решения такой задачи — проверять элементы и складывать кандидатов на удаление в отдельную коллекцию. Затем эту коллекцию удалить из исходной (рисунок 1). Второй вариант — использовать метод remove() в интерфейсе Iterator, тогда можно обойтись без дополнительной коллекции (рисунок 2) Счастливым пользователям джавы 8+ доступна короткая запись (рисунок 3): Если метод не синхронизирован, то результат будет неточным во всех вариантах — кандидаты на удаление могут появиться в коллекции уже во время обхода итератора. Удаляйте элементы с умом и делайте это красиво! #fillthegaps_mt #multithreading #java #collections

Как стать лучшим разработчиком Главное конкурентное преимущество любого специалиста — знать правила и понимать когда, где и зачем они нужны. Нормальный разработчик решает проблемы по мере поступления, учится тому, что пригодится в работе, бессистемно читает статьи по разным темам. Хороший разработчик углубляет текущие знания, смотрит лекции по другим технологиям, читает фундаментальные книги. Лучший разработчик делает то же, что и хороший. Но не просто поглощает факты, а разбирается, почему всё работает именно так. Какие границы применимости у новых знаний. Чем один подход лучше другого. Недостаточно заучить типовые ситуации и типовые решения. В лекциях даются упрощённые однобокие примеры. На каждом проекте свои проблемы, подходы и технологии. У каждой задачи несколько решений. Анализируйте то, что делаете. Даже если вы ещё джуниор или мидл, и задачи выглядят как «напиши это по подобию того». Посмотрите на задачу шире и постарайтесь понять, почему сделано так, а не иначе. Когда читаете статьи и смотрите лекции задавайте себе вопрос - как ещё решить исходную проблему? Когда мой вариант лучше варианта из статьи? Сначала будет казаться, что других достойных опций нет, но со временем вы будете видеть их всё чаще. Мгновенного профита от такого процесса не будет, но если привычка закрепится — вы будете на голову выше своих коллег. Чем выше должность - тем больше принимаемых решений и тем важнее навык критического мышления. В разработке ПО полно инертности. Однажды выбранные способы решения выбираются снова и снова. Thinking out of the box — самый редкий и ценный навык и над ним тоже нужно работать. #soft_skills

Fairness. Честная многопоточность. Одна из проблем многопоточного программирования называется starvation. Её суть в том, что поток не может получить доступ к общим ресурсам и продолжать работу. Так получается, если: - у потока низкий приоритет, - другие потоки захватывают доступ к критической секции быстрее, - поток вызвал wait() у объекта, но notify() достаётся другим потокам. Ситуация неприятная: ресурсы потока заняты, а задача не выполняется. Чтобы избежать проблем выше можно использовать средства синхронизации с флажком fairness = true. Например, Lock lock = new ReentrantLock(true); Что при этом происходит? И почему этот параметр по умолчанию false? При fairness=true преимущество получает самый долго ожидающий поток. При этом вероятность starvation ощутимо снижается. Конкретная очередность не гарантируется, так как параметр не влияет на планировщик потоков в ОС. Пропускная способность при этом ухудшается в разы Интересный факт: tryLock() не обращает внимания на параметр fairness и постарается захватить блокировку, даже если в очереди стоят другие потоки. tryLock(0, TimeUnit.SECONDS) учитывает fairness и при наличии других ожидающих потоков встанет в общую очередь. Что же делать? Использовать флажок fairness или нет? Если описанные выше проблемы возможны и критичны, надёжнее использовать tryLock с увеличивающимся временем ожидания и не полагаться на fairness. #core