#race_condition — Public Fediverse posts

Code Review Horror Stories. Часть 1: Concurrency & Memory в Go-сервисе

Продолжение прошлой статьи про ошибки на Go-собесах . В тот раз — про лайв-кодинг. Теперь — про code review: когда дают готовый сервис на ~150 строк и говорят “найди что не так, у тебя 30 минут”. Разберём по косточкам реальный код с собеседования — микросервис трекинга рекламных кликов. Багов набралось 21, поэтому делю на две части. Первая — про самое страшное: concurrency, гонки, утечки памяти и горутин. Это то, что роняет сервис в проде. Часть 2 — про API design, ошибки и graceful shutdown — выйдет следом. Актуально для Go 1.26. Из 21 бага на собесе я нашёл 18. Три самых тонких пропустил — потом, дома, перечитал спокойно и выписал. В этой части про concurrency пропустил один — TOCTOU race в дедупликации. Остальные семь — поймал. Расскажу как искал и какими красными флагами зацепился.

https://habr.com/ru/articles/1031010/

#go #golang #code_review #собеседование #конкурентность #goroutine #race_condition

Code Review Horror Stories. Часть 1: Concurrency & Memory в Go-сервисе

Продолжение прошлой статьи про ошибки на Go-собесах . В тот раз — про лайв-кодинг. Теперь — про code review: когда дают готовый сервис на ~150 строк и говорят “найди что не так, у тебя 30 минут”. Разберём по косточкам реальный код с собеседования — микросервис трекинга рекламных кликов. Багов набралось 21, поэтому делю на две части. Первая — про самое страшное: concurrency, гонки, утечки памяти и горутин. Это то, что роняет сервис в проде. Часть 2 — про API design, ошибки и graceful shutdown — выйдет следом. Актуально для Go 1.26. Из 21 бага на собесе я нашёл 18. Три самых тонких пропустил — потом, дома, перечитал спокойно и выписал. В этой части про concurrency пропустил один — TOCTOU race в дедупликации. Остальные семь — поймал. Расскажу как искал и какими красными флагами зацепился.

https://habr.com/ru/articles/1031010/

#go #golang #code_review #собеседование #конкурентность #goroutine #race_condition

Code Review Horror Stories. Часть 1: Concurrency & Memory в Go-сервисе

Продолжение прошлой статьи про ошибки на Go-собесах . В тот раз — про лайв-кодинг. Теперь — про code review: когда дают готовый сервис на ~150 строк и говорят “найди что не так, у тебя 30 минут”. Разберём по косточкам реальный код с собеседования — микросервис трекинга рекламных кликов. Багов набралось 21, поэтому делю на две части. Первая — про самое страшное: concurrency, гонки, утечки памяти и горутин. Это то, что роняет сервис в проде. Часть 2 — про API design, ошибки и graceful shutdown — выйдет следом. Актуально для Go 1.26. Из 21 бага на собесе я нашёл 18. Три самых тонких пропустил — потом, дома, перечитал спокойно и выписал. В этой части про concurrency пропустил один — TOCTOU race в дедупликации. Остальные семь — поймал. Расскажу как искал и какими красными флагами зацепился.

https://habr.com/ru/articles/1031010/

#go #golang #code_review #собеседование #конкурентность #goroutine #race_condition

Code Review Horror Stories. Часть 1: Concurrency & Memory в Go-сервисе

Продолжение прошлой статьи про ошибки на Go-собесах . В тот раз — про лайв-кодинг. Теперь — про code review: когда дают готовый сервис на ~150 строк и говорят “найди что не так, у тебя 30 минут”. Разберём по косточкам реальный код с собеседования — микросервис трекинга рекламных кликов. Багов набралось 21, поэтому делю на две части. Первая — про самое страшное: concurrency, гонки, утечки памяти и горутин. Это то, что роняет сервис в проде. Часть 2 — про API design, ошибки и graceful shutdown — выйдет следом. Актуально для Go 1.26. Из 21 бага на собесе я нашёл 18. Три самых тонких пропустил — потом, дома, перечитал спокойно и выписал. В этой части про concurrency пропустил один — TOCTOU race в дедупликации. Остальные семь — поймал. Расскажу как искал и какими красными флагами зацепился.

https://habr.com/ru/articles/1031010/

#go #golang #code_review #собеседование #конкурентность #goroutine #race_condition

Деконструкция GO: CPU, RAM и что там происходит. Многозадачность, многопоточность, кэши, проблемы. Часть 1.2

В прошлой статье я немного слукавил, сказав, что мы будем разбирать атомики, барьеры и системные вызовы. Я пару дней поразмышлял и осознал – а зачем вообще это объяснять, если мы даже не знаем про причину их возникновения и проблемы, которые они решают В части 1.1 мы рассмотрели базовые инструкции, которые выполняет наш CPU и которыми в конечном счете и являются наши прекрасные строчки на Go. Но возникает закономерный вопрос: “Окей, мы поняли как работает на одном ядре, но Go у нас во многом про многопоточку, соответственно как это будет работать на нескольких потоках?” Если что, то это часть большого цикла по разбору Go! Данная статья – это подводка уже к тому, с чем мы имеем дело в Go достаточно часто(барьеры памяти, атомики, сисколы) В этот раз будет без Go Assembler, но с +- реальными примерами, если что-то непонятно будет, то на Хабре есть классный ИИ-помощник Многозадачность Хоть мы и развенчиваем в этом цикле абстракции, придется немного к ним вернуться. Но ненадолго! Вспоминаем, как у нас выполняются инструкции в процессоре и представляем следующую конфигурацию: Есть какое-то количество ГБ RAM Есть 1 ядро CPU Соответственно в один момент CPU может выполнять ровно 1 набор инструкций Но почему-то всё во времена одноядерных CPU работало непрерывно… На самом деле нет! Работало еще как с прерываниями(не путать с теми, которые interrupt), просто настолько быстро, что мы были неспособны это осознать, а для того, чтобы успевали работать фоновые службы, приложения и что бы то ни было ещё как раз и придумали многозадачность !

https://habr.com/ru/articles/1024868/

#assembler #go #multithreading #multitasking #race_condition #cache_contention #cpu #ram #linux

Деконструкция GO: CPU, RAM и что там происходит. Многозадачность, многопоточность, кэши, проблемы. Часть 1.2

В прошлой статье я немного слукавил, сказав, что мы будем разбирать атомики, барьеры и системные вызовы. Я пару дней поразмышлял и осознал – а зачем вообще это объяснять, если мы даже не знаем про причину их возникновения и проблемы, которые они решают В части 1.1 мы рассмотрели базовые инструкции, которые выполняет наш CPU и которыми в конечном счете и являются наши прекрасные строчки на Go. Но возникает закономерный вопрос: “Окей, мы поняли как работает на одном ядре, но Go у нас во многом про многопоточку, соответственно как это будет работать на нескольких потоках?” Если что, то это часть большого цикла по разбору Go! Данная статья – это подводка уже к тому, с чем мы имеем дело в Go достаточно часто(барьеры памяти, атомики, сисколы) В этот раз будет без Go Assembler, но с +- реальными примерами, если что-то непонятно будет, то на Хабре есть классный ИИ-помощник Многозадачность Хоть мы и развенчиваем в этом цикле абстракции, придется немного к ним вернуться. Но ненадолго! Вспоминаем, как у нас выполняются инструкции в процессоре и представляем следующую конфигурацию: Есть какое-то количество ГБ RAM Есть 1 ядро CPU Соответственно в один момент CPU может выполнять ровно 1 набор инструкций Но почему-то всё во времена одноядерных CPU работало непрерывно… На самом деле нет! Работало еще как с прерываниями(не путать с теми, которые interrupt), просто настолько быстро, что мы были неспособны это осознать, а для того, чтобы успевали работать фоновые службы, приложения и что бы то ни было ещё как раз и придумали многозадачность !

https://habr.com/ru/articles/1024868/

#assembler #go #multithreading #multitasking #race_condition #cache_contention #cpu #ram #linux

Деконструкция GO: CPU, RAM и что там происходит. Многозадачность, многопоточность, кэши, проблемы. Часть 1.2

В прошлой статье я немного слукавил, сказав, что мы будем разбирать атомики, барьеры и системные вызовы. Я пару дней поразмышлял и осознал – а зачем вообще это объяснять, если мы даже не знаем про причину их возникновения и проблемы, которые они решают В части 1.1 мы рассмотрели базовые инструкции, которые выполняет наш CPU и которыми в конечном счете и являются наши прекрасные строчки на Go. Но возникает закономерный вопрос: “Окей, мы поняли как работает на одном ядре, но Go у нас во многом про многопоточку, соответственно как это будет работать на нескольких потоках?” Если что, то это часть большого цикла по разбору Go! Данная статья – это подводка уже к тому, с чем мы имеем дело в Go достаточно часто(барьеры памяти, атомики, сисколы) В этот раз будет без Go Assembler, но с +- реальными примерами, если что-то непонятно будет, то на Хабре есть классный ИИ-помощник Многозадачность Хоть мы и развенчиваем в этом цикле абстракции, придется немного к ним вернуться. Но ненадолго! Вспоминаем, как у нас выполняются инструкции в процессоре и представляем следующую конфигурацию: Есть какое-то количество ГБ RAM Есть 1 ядро CPU Соответственно в один момент CPU может выполнять ровно 1 набор инструкций Но почему-то всё во времена одноядерных CPU работало непрерывно… На самом деле нет! Работало еще как с прерываниями(не путать с теми, которые interrupt), просто настолько быстро, что мы были неспособны это осознать, а для того, чтобы успевали работать фоновые службы, приложения и что бы то ни было ещё как раз и придумали многозадачность !

https://habr.com/ru/articles/1024868/

#assembler #go #multithreading #multitasking #race_condition #cache_contention #cpu #ram #linux

Деконструкция GO: CPU, RAM и что там происходит. Многозадачность, многопоточность, кэши, проблемы. Часть 1.2

В прошлой статье я немного слукавил, сказав, что мы будем разбирать атомики, барьеры и системные вызовы. Я пару дней поразмышлял и осознал – а зачем вообще это объяснять, если мы даже не знаем про причину их возникновения и проблемы, которые они решают В части 1.1 мы рассмотрели базовые инструкции, которые выполняет наш CPU и которыми в конечном счете и являются наши прекрасные строчки на Go. Но возникает закономерный вопрос: “Окей, мы поняли как работает на одном ядре, но Go у нас во многом про многопоточку, соответственно как это будет работать на нескольких потоках?” Если что, то это часть большого цикла по разбору Go! Данная статья – это подводка уже к тому, с чем мы имеем дело в Go достаточно часто(барьеры памяти, атомики, сисколы) В этот раз будет без Go Assembler, но с +- реальными примерами, если что-то непонятно будет, то на Хабре есть классный ИИ-помощник Многозадачность Хоть мы и развенчиваем в этом цикле абстракции, придется немного к ним вернуться. Но ненадолго! Вспоминаем, как у нас выполняются инструкции в процессоре и представляем следующую конфигурацию: Есть какое-то количество ГБ RAM Есть 1 ядро CPU Соответственно в один момент CPU может выполнять ровно 1 набор инструкций Но почему-то всё во времена одноядерных CPU работало непрерывно… На самом деле нет! Работало еще как с прерываниями(не путать с теми, которые interrupt), просто настолько быстро, что мы были неспособны это осознать, а для того, чтобы успевали работать фоновые службы, приложения и что бы то ни было ещё как раз и придумали многозадачность !

https://habr.com/ru/articles/1024868/

#assembler #go #multithreading #multitasking #race_condition #cache_contention #cpu #ram #linux

Начинаем в багбаунти: как найти ошибки в бизнес‑логике

Всем привет! Меня зовут Роман. В ИТ я больше семи лет: начинал с разработки, а теперь занимаюсь AppSec и параллельно пробую себя в багхантинге. Сейчас вхожу в топ-25 рейтинга на Standoff Bug Bounty. Здесь я выступаю как начинающий исследователь багов и буду рад поделиться своими наработками. Сегодня обсудим уязвимости бизнес‑логики — сложные и часто недооцененные ошибки, способные привести к серьезному ущербу. Разберем, как их находить, почему они опасны и что делает охоту за ними в багбаунти такой увлекательной. Погнали!

https://habr.com/ru/companies/pt/articles/1014346/

#bug_bounty #broken_access_control #race_condition #jwt #dos #standoff #bugs #api #fuzzing #auth_bypass

Начинаем в багбаунти: как найти ошибки в бизнес‑логике

Всем привет! Меня зовут Роман. В ИТ я больше семи лет: начинал с разработки, а теперь занимаюсь AppSec и параллельно пробую себя в багхантинге. Сейчас вхожу в топ-25 рейтинга на Standoff Bug Bounty. Здесь я выступаю как начинающий исследователь багов и буду рад поделиться своими наработками. Сегодня обсудим уязвимости бизнес‑логики — сложные и часто недооцененные ошибки, способные привести к серьезному ущербу. Разберем, как их находить, почему они опасны и что делает охоту за ними в багбаунти такой увлекательной. Погнали!

https://habr.com/ru/companies/pt/articles/1014346/

#bug_bounty #broken_access_control #race_condition #jwt #dos #standoff #bugs #api #fuzzing #auth_bypass

Начинаем в багбаунти: как найти ошибки в бизнес‑логике

Всем привет! Меня зовут Роман. В ИТ я больше семи лет: начинал с разработки, а теперь занимаюсь AppSec и параллельно пробую себя в багхантинге. Сейчас вхожу в топ-25 рейтинга на Standoff Bug Bounty. Здесь я выступаю как начинающий исследователь багов и буду рад поделиться своими наработками. Сегодня обсудим уязвимости бизнес‑логики — сложные и часто недооцененные ошибки, способные привести к серьезному ущербу. Разберем, как их находить, почему они опасны и что делает охоту за ними в багбаунти такой увлекательной. Погнали!

https://habr.com/ru/companies/pt/articles/1014346/

#bug_bounty #broken_access_control #race_condition #jwt #dos #standoff #bugs #api #fuzzing #auth_bypass

Начинаем в багбаунти: как найти ошибки в бизнес‑логике

Всем привет! Меня зовут Роман. В ИТ я больше семи лет: начинал с разработки, а теперь занимаюсь AppSec и параллельно пробую себя в багхантинге. Сейчас вхожу в топ-25 рейтинга на Standoff Bug Bounty. Здесь я выступаю как начинающий исследователь багов и буду рад поделиться своими наработками. Сегодня обсудим уязвимости бизнес‑логики — сложные и часто недооцененные ошибки, способные привести к серьезному ущербу. Разберем, как их находить, почему они опасны и что делает охоту за ними в багбаунти такой увлекательной. Погнали!

https://habr.com/ru/companies/pt/articles/1014346/

#bug_bounty #broken_access_control #race_condition #jwt #dos #standoff #bugs #api #fuzzing #auth_bypass

Нагрузочное тестирование с нуля: наши грабли, гонка за токеном и рабочий чек-лист

Привет, хабровчане! Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. Все мы знаем эту боль: фича идеально работает на деве и предпроде, проходит все тесты, а когда под реальной нагрузкой на нее заходят сотни пользователей одновременно - все начинает тормозить, сыпать ошибками или просто падать. Чтобы этого избежать, мы решили, что НТ должно стать обязательным этапом для всех фичевых задач, которые серьезно меняют логику, затрагивают запросы к серверу, кэширование или обработку данных. Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

https://habr.com/ru/articles/1013866/

#нагрузочное_тестирование #race_condition #кэширование_данных #memcached #оптимизация_производительности #чеклист_нагрузочного_тестирования #кейс_нагрузочного_тестирования #гонка_процессов #метрики #анализ_работы_web_сервисов

Ловушки volatile, DCL и синхронизации в Java

А что если окажется, что простые знания на самом деле более нюансированные, а старые знакомые, такие как Double-checked locking, являются неоднозначными? Именно на такие мысли наталкивает изучение кода реальных проектов. Результаты этого исследования мы и рассмотрим в этой статье.

https://habr.com/ru/companies/pvs-studio/articles/819625/

#volatile #java #dcl #doublechecked_lock #doublechecked_locking #race_condition #dbeaver #parallel_programming #параллельное_программирование #состояние_гонки