Сегодня буду здесь в 17 55) Залетайте на стрим Девушки в IT ☄️
Немного расскажу про трудности на первом месте работы
ПС пс именно после этой работы я ушла в менеджмент
Немного расскажу про трудности на первом месте работы
ПС пс именно после этой работы я ушла в менеджмент
Youtube
- YouTube
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
🔥15
Зачем на собеседованиях задают вопросы про многопоточность? 🤤 🤤 🤤
Ребята, которые только вкатываются в IT и готовятся к техническим интервью часто спрашивают:
Разве для решения задач бизнеса используются synchronized блоки и ExecutorServicы? Все же реализовано под капотом фреймворков!
Ответ на это – да, используется, и вот почему:
🐾 Параллельная обработка запросов
Сервис обрабатывает каждый REST запрос в отдельном потоке, это реализовано на уровне servlet контейнера. Представьте, что поступает запрос на обновление данных клиента, требующий взаимодействия с тремя разными микросервисами. То есть поток отправит запрос в первый сервис, подождет ответ, после пойдет во второй и тд. Это может занять значительное время💩
Однако, используя многопоточность с помощью таких инструментов, как ExecutorService, Future, CompletableFuture, можно параллельно выполнять эти операции, существенно ускоряя общее время обработки.
🐾 Управление состоянием в многопоточной среде
Если в коде есть объект с изменяемым состоянием, доступ к которому осуществляется из нескольких потоков, могут возникнуть проблемы синхронизации. Потоки могут одновременно изменять состояние объекта, что приведет к его некорректному изменению.
Чтобы предотвратить это, необходимо использовать такие механизмы как synchronized блоки, атомарные операции, блокировки или многопоточные коллекции.
🐾 Повышение производительности
Многопоточность важна для оптимизации задач, которые можно разделить на независимые подзадачи. Например, при обработке большого количества сообщений из Kafka, каждое сообщение требует валидации, выполнения бизнес-логики, обращения к внешним сервисам за дополнительной информацией и обновления записей в базе данных. Используя многопоточность, можно параллельно обрабатывать эти шаги для разных сообщений, значительно ускоряя общий процесс обработки🕺
🟥 Знание многопоточности является ключевым для разработки эффективных и надежных сервисов.
Ставь единорожка, если хочешь увидеть решение возникающих в проде проблем многопоточности ❤️🔥 ❤️
Ребята, которые только вкатываются в IT и готовятся к техническим интервью часто спрашивают:
Разве для решения задач бизнеса используются synchronized блоки и ExecutorServicы? Все же реализовано под капотом фреймворков!
Ответ на это – да, используется, и вот почему:
Сервис обрабатывает каждый REST запрос в отдельном потоке, это реализовано на уровне servlet контейнера. Представьте, что поступает запрос на обновление данных клиента, требующий взаимодействия с тремя разными микросервисами. То есть поток отправит запрос в первый сервис, подождет ответ, после пойдет во второй и тд. Это может занять значительное время💩
Однако, используя многопоточность с помощью таких инструментов, как ExecutorService, Future, CompletableFuture, можно параллельно выполнять эти операции, существенно ускоряя общее время обработки.
Если в коде есть объект с изменяемым состоянием, доступ к которому осуществляется из нескольких потоков, могут возникнуть проблемы синхронизации. Потоки могут одновременно изменять состояние объекта, что приведет к его некорректному изменению.
Чтобы предотвратить это, необходимо использовать такие механизмы как synchronized блоки, атомарные операции, блокировки или многопоточные коллекции.
Многопоточность важна для оптимизации задач, которые можно разделить на независимые подзадачи. Например, при обработке большого количества сообщений из Kafka, каждое сообщение требует валидации, выполнения бизнес-логики, обращения к внешним сервисам за дополнительной информацией и обновления записей в базе данных. Используя многопоточность, можно параллельно обрабатывать эти шаги для разных сообщений, значительно ускоряя общий процесс обработки
Please open Telegram to view this post
VIEW IN TELEGRAM
🦄39🔥8 3💯1 1
Вчера снимала видео на YouTube - канал ⭐ ⭐
Сегодня будем монтировать и делать обложку, думаю, в ближайшие дни получится выложить
💘 Сценарий писала неделю, первое видео для меня очень важно, и я надеюсь на Вашу поддержку 🎀
Сегодня будем монтировать и делать обложку, думаю, в ближайшие дни получится выложить
Please open Telegram to view this post
VIEW IN TELEGRAM
Выложила на YouTube канал видео о том, как я вошла в IT 👍
В коммерческую разработку я пришла не так давно, так что даю свежую информацию по устройству на работу, также мое первое место работы - оказалось лютым адом, из которого у меня получилось выбраться. Так что это видео будет полезно как вкатунам, так и ребятам с опытом, которые находятся в компании с неблагоприятными условиями
Надеюсь, вам оно откликнется
Приятного просмотра💝 🙂
видосик тут
В коммерческую разработку я пришла не так давно, так что даю свежую информацию по устройству на работу, также мое первое место работы - оказалось лютым адом, из которого у меня получилось выбраться. Так что это видео будет полезно как вкатунам, так и ребятам с опытом, которые находятся в компании с неблагоприятными условиями
На своем пути к работе мечты я прошла через много трудностей, главная из них - профессиональное выгорание. Мне потребовалось много времени, чтобы из него выбраться, об этом тоже рассказываю в видео
Надеюсь, вам оно откликнется
Приятного просмотра
видосик тут
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
КАК Я ВОШЛА В IT | ВЫГОРАНИЕ НА ПЕРВОМ МЕСТЕ РАБОТЫ
В этом видео я поделюсь историей о том, как мне удалось войти в IT c нуля, справиться с эмоциональным выгоранием на работе и выйти из депрессивного состояния. Расскажу о своей первой работе в IT, как я ушла из разработки в менеджмент, а потом вернулась обратно)…
🔥21 10❤7🍓3🍾1
УТЕЧКА ПАМЯТИ ИЛИ НОРМАЛЬНОЕ ПОВЕДЕНИЕ СИСТЕМЫ?
Проведя нагрузочное тестирование, было обнаружено, что после окончания обработки входящих запросов объем памяти, используемый подой, не уменьшается. (Рисунок 1)
Первое предположение - сборщик мусора не успел удалить недостижимые объекты.
Решила проверить теорию: увеличила кол-во отправляемых запросов в одном батче, отправляла их с таймаутом и смотрела на поведение графика. Если бы кол-во используемой памяти оставалось на одном уровне/уменьшалось, можно было бы сделать вывод, что проблемы нет, память постепенно очищается.
Однако кол-во используемой памяти только увеличивалось. (Рисунок 2)
Из-за чего был сделан вывод, что утечка есть, нужно делать heap dump🔫
Я выгружала cнимок памяти с помощью endpoint’а актуатора heapdump, файл был очень большой, поэтому загрузить, кинув рест запрос в браузере, не получилось - отправляла curl'ом в терминале (git bash).
Для анализа снимка выбрала Eclipse Memory Analyzer, зашел удобный и понятный интерфейс у этого инструмента. Сделала 2 снимка памяти: во время нагрузки на сервис и после обработки всех входящих запросов. В принципе по самим размерам файлов можно было сделать вывод, что память очищается - размер heap dump’а после обработки был меньше в 4 раза, чем размер снимка памяти сервиса во время нагрузки. Однако все равно загрузила в анализатор и убедилась, что утечек нет, все неиспользуемые объекты были удалены. При этом память, используемая подой, оставалась на том же уровне после нагрузки💩
Первая мысль, которая мне пришла в голову - может, другие контейнеры, которые крутятся с моим сервисом на одной поде столько жрут? Очень сомнительная идея, ведь до старта нагрузки использовалось памяти намного меньше, а они также работали. Логично было бы, чтобы сразу при старте поды график рос сильно вверх.
Проведя нагрузочное тестирование, было обнаружено, что после окончания обработки входящих запросов объем памяти, используемый подой, не уменьшается. (Рисунок 1)
Первое предположение - сборщик мусора не успел удалить недостижимые объекты.
Решила проверить теорию: увеличила кол-во отправляемых запросов в одном батче, отправляла их с таймаутом и смотрела на поведение графика. Если бы кол-во используемой памяти оставалось на одном уровне/уменьшалось, можно было бы сделать вывод, что проблемы нет, память постепенно очищается.
Однако кол-во используемой памяти только увеличивалось. (Рисунок 2)
Из-за чего был сделан вывод, что утечка есть, нужно делать heap dump
Heap dump
- снимок памяти кучи, хранит в себе информацию о всех используемых объектах. На основе него можно сделать вывод, какие объекты не удаляются, хотя, по ожиданиям разработчика, удаляться должны.
Я выгружала cнимок памяти с помощью endpoint’а актуатора heapdump, файл был очень большой, поэтому загрузить, кинув рест запрос в браузере, не получилось - отправляла curl'ом в терминале (git bash).
Для анализа снимка выбрала Eclipse Memory Analyzer, зашел удобный и понятный интерфейс у этого инструмента. Сделала 2 снимка памяти: во время нагрузки на сервис и после обработки всех входящих запросов. В принципе по самим размерам файлов можно было сделать вывод, что память очищается - размер heap dump’а после обработки был меньше в 4 раза, чем размер снимка памяти сервиса во время нагрузки. Однако все равно загрузила в анализатор и убедилась, что утечек нет, все неиспользуемые объекты были удалены. При этом память, используемая подой, оставалась на том же уровне после нагрузки
Первая мысль, которая мне пришла в голову - может, другие контейнеры, которые крутятся с моим сервисом на одной поде столько жрут? Очень сомнительная идея, ведь до старта нагрузки использовалось памяти намного меньше, а они также работали. Логично было бы, чтобы сразу при старте поды график рос сильно вверх.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9🦄4🍓3