[музыка] [аплодисменты] [музыка] [аплодисменты] Всем привет Сегодня у нас снова встреча клуба программистов и если Вы в курсе вы у нас может быть в чате сидите то знаете что Нина недавно написала доклад о статью на хабре про то как работает сборщик мусора в гол А ну статья это конечно хорошо но некоторые люди проще воспринимают информацию которая вот визуально Передается ли голосом поэтому мы подумали что еще и доклад Было бы очень здорово поэтому Нина еще и сделали доклад сегодня мы поговорим как раз про эту тему про сборщик мусора про язык но прежде чем мы начнем Я напомню что наша трансляция доступна и возможно благодаря компании btg.ru которая проводит и такой вот видение слова сразу передали мы будем тебя слушать Спасибо еще раз ребята позволяет нам использовать их я на самом деле сейчас сразу переключаюсь на презентацию если позволите Скажите видно ли моя сейчас подождем А все я тебя вижу и наверное сразу попросим Наташа можно меня убрать из сосать или Спасибо большое комментарии мы обязательно Все прочитаем на вопросы ответим но в конце нашей презентации вот а пока что я представлюсь Меня зовут Нина пакшина я больше двух лет программирую ногу до этого я писала активное на питоне Вот и собственно я хочу сегодня рассказать доклад о том как управлять памятью сборщиком мусора в год тема Очень актуальная Потому что рано или поздно любой программист сталкивается с тем что ему нужно как-то оптимизировать свой код по потреблению памяти по быстродействию и соответственно в год Есть такие инструменты но может быть они не всегда доступны на поверхности собственно я думаю что вы все знаете что в го данные хранятся в двух принципиально разных областях памяти это стек и куча если данные попадают в стек то это очень хорошо потому что стек автоматически управляется рантаймом Go выделение сохранения данных в стек и получения данных стека занимает очень мало времени в принципе так работает как очередь лифа ласты и если как бы проанализировать что же может попасть в стек это все те данные которые гокомпиляторы которым компилятор может проанализировать как долго они будут жить в программе и как много места они будут занимать в программе в основном это различные локальные переменные функции аргументы которые передаются функции возвращаемые значения если бы все данные в программе попадали в стек Было бы очень хорошо и Наверное мы с вами Сейчас бы не встречались К сожалению так и не бывает и иногда компилятор не может спрогнозировать Как долго будут жить данные в программе и как много места они будут снимать и в таком случае данные попадают в кучу куча это как бы название области памяти говорит само за себя это соответственно Огромная область памяти которые шалится между всеми потоками и соответственно она используется для хранения динамической памяти и вот если данные уже попали в кучу то здесь есть подводные камни потому что кучей нужно управлять если наши динамическая память будет постоянно расти наша программа будет постоянно использовать виртуальную память и соответственно в какой-то момент она может есть все доступные ресурсы в данной исполнительной среде соответственно для того чтобы управлять кучей есть специальные механизм который отдельно вызывается это так называемый сборщик мусора или по-английски собственно сегодня в докладе я попытаюсь раскрыть моменты специфические моменты того как он работает а если мы зайдем в IQ галанга где там самые популярные вопросы о том как работает Go и спросим у них Где же сохранится наша переменная которую мы используем в программе в стеке или в куче то там дается очень простой лаконичный ответ о том что вам не нужно знать об этом то есть не забивайте свою красивую голову такой ерундой компилятор он как-то сам решит что сохранять в стек что сохранять в кучу вы просто хорошо Пишите но нам Конечно такой подход не очень подходит потому что мы хотим с оптимизировать нашу программу и Хоть как-то ее улучшить значит что мы можем сделать мы можем воспользоваться так называемым эскейп анализом в принципе для того чтобы им воспользоваться можно запустить программу или сбил здесь программы с определенным флагом то есть флаг флаг м ну и чтобы собственно посмотреть как это все работает я сейчас пишу небольшую программку которая у меня уже записана что у меня здесь в программе есть в этой программе Я создаю массив который занимает меньше 10 мегабайт Я создаю массив который занимает больше 10 мегабайт Я создаю слайс при аллоцированный который меньше 64 килобайт и больше 64 килобайт значит если я сейчас запущу программу с этим флагом у меня будет произведен анализе статного хода данного хода значит что я вижу массив который меньше 10 мегабайт про него ничего не написано потому что он был создан стеки массив Который больше 10 мегабайт соответственно утек в кучу и Что касаемо слайса при алоцированного которое меньше 64 килобайт он остается в стеке а то что больше он утекает в кучу то есть принципе вот у нас первый такой инструмент который позволит оптимизировать Вашу программу Мы видим что большие куски памяти они утекают в кучу небольшие куски памяти остаются в стеке и таким образом мы можем оптимизировать наш код и соответственно меньше нагрузки на нашу память системы но опять же таки к сожалению мы не все можем запихнуть в стек и что-то все-таки сохраняется в куче И как я уже говорила на помощь приходит сборщик мусора который позволяет управлять этой кучей в год сборщик мусора основан на базе алгоритма Mark and swip там есть две основные стадии работы Первое это стадия маркировки когда начиная с корневого объекта коллектор проходит по всему дереву объектов и смотрит какие объекты все еще используются в коде и эти объекты он помечает в качестве живых и следующая стадия это стадия очистки соответственно все те объекты которые не используются программы не были помечены как живые они удаляются из кучи Вот еще один такой интересный момент если вы читали прочь коллектор то часто в русскоязычных статьях По крайней мере я встречаю то что а там используется трехсветный алгоритм Mark and swip Но на самом деле в самой документации и в гайде по горипочка коллектору они почему-то избегают этого названия Хотя используют такие понятия как помечание данных серыми черными и белыми вот если вам интересно углубиться в то как работает сборщик мусора есть два таких документа первый документ это гайд по карточка лектору здесь рассказывается в общем как бы в общих терминах как она работает и есть непосредственно Гош на реализация сборщика мусора здесь тоже очень много всего интересного можно почитать вот поэтому потом презентация будет доступна ссылки будут доступны обязательно посмотрите значит вообще почему мы говорим про сборщик мусора в чем в чем его проблема собирает мусор и классно нам не нужно думать он же автоматически запускается но к сожалению сборщик мусора потребляет ресурсы системы в том числе очень важные ресурсы системы это физическая память и процессорное время причем эти две величины Они обратно пропорциональны друг другу то есть если например мы сборщик мусора запускаем Часто у нас физическая память заменяемая занимаемая кучей она соответственно маленькая мы мало памяти занимаем но при этом сборщик мусора запускается часто и он тратит процессорное время А если мы сборщик мусора будем запускать реже то соответственно куча будет расти занимать больше памяти получается сборщики мусора самое главное это некий баланс между временем и памятью Еще один очень важный концепция которая используется в отношении сборщиков мусора это так называемый stop the world есть реализация сборщика мусора когда начинается сборка мусора все полезное исполнение программы останавливается и начинает работать только сборщик мусора поэтому так и называется stop the world то есть остановить весь мир но современные сборщики мусора они не останавливают полностью выполнение полезной работы Вот например в нет полной остановки но все равно в двух моментах остановка исполнения кода происходит это происходит на стадии подготовки перед маркировкой и на стадии завершения маркировки что кстати очень хорошо что на во время самой маркировки когда собственно коробочка Лектор проходит по всему дереву объе ктов кучи исполнение кода не останавливается Это значит что как бы нет зависимости от размера кучи чем больше куча Чем дольше он будет проходить по дереву объектов тем как бы дольше будет простой здесь такого нет он более сбалансированный алгоритм чистки и собственно тоже Вы можете про это об этом почитать в исходном файле реализации сборщика мусора очень интересно чтобы понять о том когда запускается у нас сборщик мусора нужно ознакомиться с двумя понятиями это живая Куча и новая куча значит что происходит вот у нас в какой-то момент отработал в предыдущем цикле сборщик мусора он удалил все ненужные объекты и остались объекты которые активно используются нашей программой это называется Живая Куча и По мере того как кот исполняется здесь у нас по координате X соответственно время начинает расти новая куча То есть куча которая сборщик мусора еще не проанализировал И как только новая куча занимает сто процентов от живой кучи запускается сборщик мусора это действие соответственно то что сейчас происходит по умолчанию Если вы не меняли никакие настройки на примере абсолютных значений Например у вас предыдущее живая куча равна 10 мегабайт получается что сборщик запустится когда общая куча будет равна 20 МБ И так каждый раз для того чтобы управлять сборщиком мусора есть специальная переменные окружения которое называется godgese и подвох это его gc заключается в том что это не абсолютно величина А это процент собственно это процент необработанный кучей от живой памяти при достижении которого будет запущена сборка мусора то есть здесь у нас сто процентов по умолчанию Ну и Собственно как я говорила что когда новая куча занимает сто процентов от живой кучи запускается сборщик мусора соответственно можем поменять используя переменную окружение либо функцию из пакета добак runtime debug и соответственно Мы можем поставить например большее значение например 1000 процентов и на сборщик мусора будет запускаться реже либо 10 процентов и у нас больше мусора будет запускаться чаще Да есть еще Кстати прямой вызов фронтаем джессия про него не буду рассказывать сегодня Давайте посмотрим как вообще выглядит на реальном примере запуск запуск сборщика мусора при различных настройках У меня опять таки все подготовлено уже есть некая программка которая запускает функцию требующую много памяти эта функция у меня выполняется в очереди соответственно определенное количество раз и я буду анализировать вот эту программу с помощью инструмента готул Trace так вот здесь я начинаю запись выходного файла который буду анализировать и по завершению программы я его останавливаю записи соответственно сохраняя Так сейчас я запущу у меня по умолчанию gody C равен 100 процентов Вот я через центр Поставила просто для наглядности у меня запустилась моя программа она сделала какие-то вычисления И теперь я проанализирую это с помощью трейсов так здесь закрою и что у нас здесь есть у нас здесь отображается собственно Как меняется по мере выполнения программы размер кучи Красная это область которая занимаемая кучей зеленые это просто фон для красоты и мы видим что вот здесь вот в Пике получается запускается сборщик мусора он освобождает память дальше снова память нарастает и так далее и мы видим что вот этот область это как раз таки новое куча она равна предыдущей нашей и также мы здесь можем посмотреть как много раз И что такое Как много раз запускаться у нас сборщик мусора так сейчас кабарный инструмент вот у нас здесь есть колонка строка JC коробочка Лектор Мы видим что сборщик мусора запускался 16 раз и выполнялся где-то 4 секунды так отлично Что будет если мы запустим сборщик мусора больше чаще Значит у меня здесь стоит 10 процентов год Джесси сейчас я перезапущу рейс и мы видим что сборщик мусора запускался чаще что размер новой кучи где-то одна десятая живой кучи И если мы проанализируем сколько раз запускался с большим мусора Увидим что это 38 раз и выполнялась и время которое затратил затрачивалось на выполнение сборки мусора это 8 секунд То есть время увеличилось и собственно Мы можем поставить процент 1000 сборщик мусора по нашим прогнозам должен запускаться гораздо реже и давайте сейчас проверим Да мы видим что сборщик мусора вообще был запущен один раз соответственно когда размер новой памяти составлял 1000 процентов от живой памяти например живая память 10 мегабайт а новая память 100 мегабайт отлично то есть мы уже видим что мы можем управлять управлять непосредственно сборщиком мусора и чистотой его использования Да и кстати получается что общее время выполнения сборки мусора 1 миллисекунда то есть чем реже мы запускаем сборку сборщик тем больше у нас память размер кучи тем меньше времени процессы тратят на на чистку памяти отлично с этим мы разобрались Но кстати да еще можно отключить сборку мусора если поставить годжи си параметр WoW или здесь написать минус 1 вы как можете вообще отключить вызов сварщика мусора но в реальной жизни все происходит не так во-первых У нас нет таких Ой сейчас Прошу прощения во-первых у нас нет таких красивых периодических выделений памяти в куче все происходит гораздо более страшнее если мы сейчас запустим реальную Как пример из реальной жизни просто немножко адаптированный мы увидим что вот она куча выделяется очень неравномерно где-то больше где-то меньше где-то пике начинает выделение памяти и так далее получается что у нас мы не можем прогнозировать по абсолютной величине сколько при каком значении будет запущен сборщик например такой Пример например значит живая куча от предыдущего цикла равна 800 мегабайт Это значит что следующий сборщик мусора будет запущен вот тогда общий размер кучи будет 1,6 Гб что что как это может вообще испортить нам жизнь теперь Представьте что у нас большая часть наших приложений запускается в docker контейнере у которого есть лимит по памяти потому что бесконечный размер памяти мы не можем предоставить и Например у нас запускается наша программа в докер-контейнере где лимит 1 гигабайт и если у нас случится такая ситуация то есть сборщик мусора вызовется теоретически Когда будет 1.6 гигабайт размер кучи у нас что произойдет правильно наш контейнер будет убит по ошибке Out of memory Давайте посмотрим как это работает Может быть я сейчас обманываю ничего такого не произойдет так у меня соответственно есть контейнер где я запускаю одну из своих программ есть докер compose Так это сейчас скрою как будто вы не видите вот эту секцию и я сейчас ой по-русски сделаю Билд моего контейнера Надеюсь это будет быстро отлично и сейчас запущу мою программу так вот я увеличу чтобы было видно соответственно у меня выполняется какие-то действия и мой кот падает с ошибкой 137 А это собственная ошибка Out of memory потому что у меня стоит лимит для моего доктора контейнера 10 мегабайт то есть какой-то момент размер кучи превышает 10 мегабайт и все моя программа мой контейнер убивается соответственно моя программа перестает выполняться соответственно простой на продакшене данные которые обрабатывались в этот раз момент убийства контейнера они все потеряны и это очень плохо что мы можем сделать с этим и на помощь нам идет веселый гофер который дает нам переменную окружение и механизм для управления памятью причем этот механизм управляет А вот этот переменное окружение оно создает общее количество памяти которое может использовать и гомео лимит Мы можем поставить в виде переменной окружения либо в виде функции Исхода из пакета runtime depack значит давайте посмотрим как Мы это можем сделать вот у меня здесь уже есть подсказочка что я просто прописываю переменную окружение и ставлю предел по памяти для всего объема ран-тайма 8 мегабайт чуть меньше чем у меня допустимая память и теперь если я Переса Беру свой образ Свой контейнер не запущу я вижу что у меня программа завершилась без ошибки соответственно никакого превышения памяти не произошло что же произошло получается как только значение памяти общее значение памяти приближается к этому пределу запускается сборщик мусора То есть получается что у меня начала приближаться к 8 мегабайтам запустился сборщик мусора собрал все неиспользуемые данные из кучи и у меня программа Не превысила этот лимит то есть отлично У нас есть инструмент который позволяет избежать этой очень неприятной ошибки но к сожалению код который мы пишем он не всегда идеален вообще утечки данных ну то есть например там утечка данных гарутинами это состояние Бага как говорят разработчики собственно этого механизма гомим такого не должно быть по идее но к сожалению код наш бывает не идеален и наша память может расти вне зависимости от нашего желания и очистки кучи соответственно у нас в гайки по горбаче коллекторы есть Очень интересный анимированный график на котором мы можем посмотреть что теоретически может возник что теоретически может возникнуть Да если общий объем Нашей памяти будет приближаться к установленному этому лимиту Вот у нас есть например по умолчанию равно 100 процентам памяти ограничивается 100 мегабайтами если и у нас соответственно размер кучи менее 50 мегабайт и в какой-то там период времени она вызывается общее исполнение программы 10 секунд если мы будем уменьшать этот лимит до тех пор до 50 Мб ничего плохого не будет происходить Но как Только у нас начинает приближаться к отметке у нас сборщик мусора будет вызываться все чаще и чаще чтобы почистить кучу до тех пор пока он не будет вызываться на сто процентов на сто процентов занимать процессорное время это значит что полезная работа не будет выполнена никогда И мы видим что время исполнения программы выросло несколько раз вообще такой режим работы называется спираль смертью То есть если не будет никаких ограничений по работе сборщика мусора он будет работать непрерывно и по мере стремления вот к этому лимиту запускаться соответственно все чаще и чаще но к счастью разработчики этого механизма подумали об этом и соответственно они сделали гомим лимит мягким управлением памяти Это значит что гомельнимет не дает стопроцентной гарантии гарантии соблюдения своего лимита то есть да мы установим 10 мегабайт например но мы позволяем программе выходить за этот за этот диапазон и более того Мы ставим ограничение на использование процессорного времени не более 50 процентов и с окном исполнении сборки мусора в два умножить на Максима льное количество используемых процессоров секунд То есть получается что к сожалению гомеоми не гарантирует на сто процентов ошибки аутов Memory но она откладывает эту ошибку и если код написан правильно то в принципе мы обезопасиваем себя от такой неприятной ситуации а где же мы можем применять наши эти настройки соответственно хорошая практика Где использовать гомелимит если вы запускаете приложение одно приложение в одном контейнере то вы можете поставить предел по памяти по используемой памяти 90 95 процентов и в таком случае с большой вероятностью избежите ошибки аутофанаре Дальше например если вы используете в коте какую-то библиотеку которая требует много ресурсов Вы можете динамически управлять лимитом памяти например уменьшать количество используемой памяти для данного куска кода и Например если вы запускаете Go программу в виде скрипта то есть допустим что значит просто вы один раз запустили какую-то программу например по крону она выполнилась и потом умерла соответственно всю память за собой у них уничтожила Вы можете вообще выключить сборщик мусора но при этом поставить лимит по памяти Это значит что у вас не будет вероятности того что в какой-то момент куча вырастет настолько что уронит наш контейнер и где не стоит применять Гомель значит если вы уже используете приложение в среде где мало памяти или например в среде где используются другие программы То есть вы ей не управляете и Например если у вас программа используют входные данные используют память используется пропорционально входным данным например Это какой-то консольный инструмент или настольное приложение Здесь тоже лучше не ограничивать предел по памяти используемый соответственно у нас два таких инструмента которые могут упростить нашу жизнь на самом деле у меня такая проблема была собственно Почему я стал изучать этот момент потому что у меня в какой-то момент использования общей памяти превысило доступный лимит и увеличивать размер контейнера Я уже не могла и поэтому я поставила мягкое управление где-то на 90 процентов от лимита доступного доступного для данного контейнера и пока что вроде таких случаев Out Of Family ошибки у меня не возникало и еще в дополнительно Я хочу рассказать еще про два очень интересных инструментов которые тоже позволят вам оптимизировать запуск сборщика мусора значит первый инструмент это сингпул это так называемый пул объектов как он соответственно работает сейчас на примере простого кода мы выделяем некую некий пул объектов определенного типа соответственно из этого пола объектов Мы берем объекты для использования в нашем коде и затем после того как Мы отработали эти объекты внутри года мы возвращаем объекты назад в пол то есть что в чем здесь вообще плюс зачем это нужно получается Мы один раз аллоцируем память и после этого мы переиспользуем объекты нам нет необходимости задного создавать эту эти объекты в области памяти мы здесь экономим на времени создания новых новых объектов памяти тоже показать как это работает возьмем наш предыдущий скриптик и здесь Я буду использовать соответственно я буду получать из Пула объекты для использования и потом после того как я их отработал я буду возвращать их назад в полуобъектов и здесь у меня по умолчанию соответственно я напомню как это выглядело как выглядела потребление кучи так соответственно нас для объектов периодически в куче выделяется какая-то память и после того как я использую singpool Мы видим что новые память в куче не выделяется потому что мы всякий раз пили используем объекты которые уже были аллоцированы значит Какие особенности сингпул Да мы повторно используем временные объекты эти объекты могут быть только определенного типа то есть если мы там работаем со слайсами создаем пул для слайсов если с синтами и так далее К сожалению здесь нет гарантии долгосрочное хранение данных потому что в любой момент коллектор может посчитать что эти данные нам не нужны удалить их но при этом он потока безопасный То есть можно его шарить между несколькими грудинами И следующий инструмент он гораздо более интересный потому что это Экспериментальный инструмент он доступен в начиная с версии 1.20 называется Арена и арены работает немножко по-другому Вот у меня есть пример кода во-первых так как это Экспериментальный инструмент нам нужно определенные задать настройки чтобы разрешить его использование во-вторых мы создаем некий сегмент памяти в этот сегмент памяти мы кладем какие-то значения и этими значениями мы управляем вручную мы говорим Горбач коллектору что чтобы он их не трогал потому что как только нам они перестают быть необходимы мы можем их освободить с помощью функции мем Free В чем отличие от сингпула то что это могут быть объекты разного типа как например у меня здесь используется слайс я сохраняю здесь использую и так далее дальше то что они в принципе Арена по идее Создана для того чтобы использоваться с большим куском памяти если нам что-то нужно создать какую-нибудь объект набор объектов и [музыка] соответственно [музыка] мы не будем алоцировать эти объекты в куче А мы будем хранить их варенье и соответственно мы не будем вызывать Горбач коллектор чтобы их собирать И вообще этот инструмент был разработан в Google они там его активно используют и как они утверждают что на больших кусках памяти они экономят до 15 процентов процессорного времени то есть очень такой хороший результат Значит мы можем создавать несколько Арена в разных частях кода Единственное что Арена не является потоком безопасной то есть мы создаем только в рамках одной рутины и соответственно если нам уже не нужно использовать этот кусок памяти моего освобождаем не вызывая коробочка лектор и еще если нам вдруг необходимо этот кусок памяти сохранить долгосрочно мы можем переместить его в кучу с помощью специальной функции но опять же таки как говорю это инструмент пока что Экспериментальный его не рекомендуют использовать в продакшене потому что у него могут быть всякие подводные камни в использовании но я думаю что в ближайших релизах он будет уже включен как такой доступный инструмент а что я могу сказать вообще оптимизация программы по времени исполнения и по затраченной памяти это очень огромный Пласт работ очень огромный Пласт инструментов которые можно изучать долго-долго углубляться вглубь Вот и я хотела просто верхний уровень показать что Вы можете сделать чтобы управлять своим кодом и соответственно Надеюсь что доклад был интересным для вас полезным Может быть вы пойдете поставите себе гомелем лимит в Свой контейнер может быть нет может быть Вам Достаточно того как работает сборщик мусора по умолчанию но как минимум когда Вас на собеседование будут спрашивать коллектор вы уже будете знать что отвечать спрашивать часто ладно это была шутка вот в принципе Вы можете прочитать статью про управление памятью на хабре Первая ссылка еще здесь блок на медиуме где я пишу статьи на английском языке гораздо чаще пишу чем на Хабар вот тоже можете подписываться читать создавать вопросы Ну и собственно на этом все последним слайдом вы сейчас пишите комментарии задавайте вопросы и собственно последний слайд это список неудачных генерации гоффера все изображения я генерировала с помощью Microsoft Bing Creator Image Creator и вот здесь галерея очень неудачных офферов можете посмеяться или устрашаться все Марк Если есть вопросы Буду рада их услышать Да спасибо большое Очень хорошие доклад технические глубокий я еще и статью помню что вот она как раз очень понравилась вопрос К сожалению очень много но это как раз бывает почему-то техническими докладами Потому что люди видимо все послушали все хорошо просит ссылку на презентацию И после этого когда я сказал да Хорошо я попрошу говорят А еще ссылку пожалуйста на репозиторий с кодом а вот репозиторий с кодом Я тогда создам его и тоже прикреплю свою презентацию потому что пока что у меня локального Ну да думаю полезно будет и сделали комментарии о том что вот сингпул очень дорогой и я там не знаю честно говоря у меня экспертизы не хватает Ну да Тоже имеет свои ограничения не стоит его пихать Куда нужно вот такое кстати одно из использования Например если вы скачиваете какой-нибудь большой файл чанками и там их обрабатываете кусочками то можно сэкономить на выделение памяти если там переиспользовать при сохранении Ну это тогда если кстати очень понятный сценарий я вот хотел вопрос такого плана задать А в каких приложениях вот эта сборка мусора начинает Ну мешать понятно что наверное где-то это нормально где-то уже нет у тебя там в опыте как-то что-то такое вот бывает Вот точно здесь сборка мусора нам будет мешать вот это вот все ну вот здесь вот вопрос именно если мы не используем это используем как бы по умолчанию сборка мусора сто процентов новой куча просто могут возникать такие ситуации когда периодически тоски или просто там много периодических тасок накладывается намного запросов у нас получается возрастает количество данных куча И если мы не поставили вот у меня собственно была такая ситуация что в какой-то момент потребление программы памяти было больше чем лимит контейнера и все упало в какой момент понятно что можно я потом разнесла периодически задачи по разному времени чтобы они пересекались но к сожалению если много запросов будет как бы Упадет и после того как ввела вот этот мягкое ограничение У меня таких ситуаций уже не было Я помню читал когда-то Сто лет назад что подобная была проблема у джавистов и они же тоже обзывал то они делали приложение которое играет на бирже с этими с валютами они в конце концов у тебя отключали сборку мусора чтобы она работает и все Слушай да вот этот механизм они его откуда-то взяли я к сожалению не помню может быть даже собственно надо освежить данные потому что да еще мне кажется я приложу еще ссылку это проползал там очень интересно собственно рассказано о том как они пришли к такому решению тоже добавлю презентацию Мне кажется я не указала хорошо И вот вопрос тоже про Арену меня я сам сценарий не очень понял Это получается что тебя ареной она создается же как у тебя получается Арена ей может несколько приложений пользоваться или это все-таки одно только как-то Ну Арена она как бы как сказать то есть она в одном потоке только может использоваться потому что не поток и безопасно и это по сути ты выделяешь некий кусок памяти Да в какой-то момент она должна [смех] так меня слышно хорошо вот то есть получается мы просто на некий кусок памяти мы отключаем сборку мусора мы говорим что вот эти вот данные ты не смотри на них в рамках одного потока в программе в приложении их может быть несколько этих между приложениями нельзя Кстати это тоже очень интересная штука то чего не хватает тем кто приходится какого-нибудь человек точно знает когда память больше не нужна замучился Но вот такие языки как ну там они этого не позволяет то есть вот ты выделил память может сами знаем когда освобождать Хорошо что есть возможность в голову этот явного указать А вот еще такой вопрос у нас же по идее в языке питон тоже сборка мусора а ты как-то сравнивала как в питоне это работает и в голову мне кажется что в голову там все-таки больше больше возможностей управления этим но я так слушай в питоне там используются ссылочная модель подсчитывается количество ссылок сколько рассылается на объект и там есть еще какой-то механизм который позволяет циклические ссылки производительности что производительнее блин Хороший вопрос Я просто питоне как раз таки со сборщиком мусора так плотно не работала Мне кажется там никто не работает такое ощущение что там и не особо не управляется я могу ошибаться Ну кстати да здесь большая проблема может быть не проблема может быть для кого-то это радость чтоб в разных языках и приморках сборщики мусора очень по-разному устроены А в некоторых языках как Java там ты можешь спорщик мусора просто подменять на какой-то другой там кстати прикольная тема такого нет пока Ну да и в Dota тоже нет но эти там самого начала с первых версий было как бы два сборщика мусора для сервера и клиента Вот такая вот была ситуация сейчас посмотрим что у нас задают вопросы чисто теоретически можно отключить сборщик мусора и получается когда арены будут уже частью основного кода писать ручную очистку только через арены освобождать все данные Но кстати да один из вариантов такой может быть пишет нам в комментарии Сережка что в одной из компаний была ситуация когда вызывали его при работе с обработкой большого файла вызывали его вот это не очень понятно сборщик мусора А может быть кстати правда можно вызвать сборщик мусора то есть там есть какой-то вот такой вызов его дергаешь у тебя запускается сборка мусора здесь можно делать а в голову такого нет или есть но честно я его плотно не трогала насколько понимаю Он как раз таки вызывает Ну да по идее это как раз очень странная ситуация когда ты говоришь ребята я сам хочу знать советы Хотя Ром чтобы найти не забивать себе голову совершенно не нужны информации так что-то еще может быть какие-то вопросы пока вопросов других Вопросов нет хорошо Тоже вопросы закончились вот тогда я тебя хочу просто поблагодарить за подготовленный доклад и за написанную статью и я очень рад что И то и другое теперь у нас в Интернете потому что ну мое личное мнение что очень важно нам делиться информацией записывайте выкладывать потому что потом лет через 5 кто-то придет посмотрит и скажет А вот именно эта информация не хватало очень хорошо изложена поэтому хорошо то что мы не просто друг друга рассказываем еще и оставляем след в интернете Спасибо нашим зрителям посмотрел кстати сама идея создать такую статью она родилась потому что меня спросили о том как работать и я об этом не знала пошла читать исходник и соответственно узнала Много всего нового узнала хорошо Значит правильно человек сделал который тебе задал такой вопрос Спасибо компании Всем пока хорошего дня пока [музыка] [аплодисменты] [музыка] [аплодисменты]