Что происходит с анонимной GoRutines после её завершения?

Question

[kool2009]

Конкретно интересует, как ведёт себя память и нужно ли вызывать runtime.GC() после завершения анонимной горутины, или анонимная горутина высвобождает память после завершения?

Comments

[Everything_is_bad]

что написано в доках?и где вообще явно вызывают GC, кроме редких особых случаев?

Answer 1

[calculator212]

Если всё отрабатывается корректно, то в 99% случаев это не нужно. Память высвободится не сразу, а в момеyт того как будет вызван сборщик мусора автоматически, для оптимизации сборки мусора он не вызывается каждый раз когда нужно освободить память. Вручную gc вызывают довольно редко т.к. это нужно только в специфических кейсах. Но если у вас память утекает, то gc с этим ничего сделать не сможет

Comments

[kool2009]

Спасибо. Вот я и спрашиваю. В доках написано, что высвобождается, но при запуске с колличеством в лимит памяти должно работать, но сборщик мусора их убрать не успевает, вот и крашится по лимиту памяти. А то тут комментаторы набежали, типа читай доки, доки то читать умею, но при запуске софт падает по лимиту памяти. Те. сама горутина за собой не приберается и это делает GC. Т.о. получается в мелких задачах с большим колличеством потоков можно упасть в лимит памяти т.к. GC не успевает прибраться и прихдится его вызывать явно.

[calculator212]

сборщик мусора их убрать не успевает

В целом в таком случае можно попробовать вызывать сборщик принудительно, если не поможет то тут либо пересматривать как программа выделяет ресурсы, либо докидывать память.

Те. сама горутина за собой не приберается и это делает GC

Так и есть

Т.о. получается в мелких задачах с большим колличеством потоков можно упасть в лимит памяти т.к. GC не успевает прибраться и прихдится его вызывать явно.

Упасть из-за нехватки памяти можно и в программе и без горутин, сами по себе они не занимают много памяти. И в целом если горутин много, то программы чаще упираются в процессор чем в память. И в целом если горутин много и их нужно ограничивать, то проблему часто решает воркер пул, который не позволит создать больше горутин чем задано. Честно говоря я ни разу не встречался с тем, что проблемы были имеено в горутинах, обычно проблемы либо в архитектуре, либо в целом с выделением памяти

[kool2009]

calculator212,

И в целом если горутин много и их нужно ограничивать, то проблему часто решает воркер пул, который не позволит создать больше горутин чем задано. Честно говоря я ни разу не встречался с тем, что проблемы были имеено в горутинах, обычно проблемы либо в архитектуре, либо в целом с выделением памяти

С этим полностью согласен. Просто один раз, на микро задачах встал в ступор, вызывать в многопоточном режиме пробовал, долго т.к. задал потоков сколько ядер (32) и потом в 3 раза больше (96) (много этих микро задачь, но проц они не загрузили на 100%), в одном потоке, так-же долго, т.к. много этих задачь. Прочитал, что горутина после смерти чистит мять, решил попробовать в цикле с вызовом go otherfunction(), и упал в лимит по памяти. Вот тут и созрел вопрос, как так, но в итоге то элегантно решил свой вопрос, но сути это не решало. ))) Спасбо, очень помогли.

[calculator212]

много этих микро задачь, но проц они не загрузили на 100%

В целом горутины не факт что будут исполнятся на разных(всех) ядрах, также задачи сами по себе могли не требовать полной загрузки проца.