<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Goroutines on Rohit Garg</title><link>https://rohit-garg.me/tags/goroutines/</link><description>Recent content in Goroutines on Rohit Garg</description><generator>Hugo</generator><language>en</language><copyright>© Rohit Garg</copyright><lastBuildDate>Thu, 30 Apr 2026 10:00:00 +0530</lastBuildDate><atom:link href="https://rohit-garg.me/tags/goroutines/index.xml" rel="self" type="application/rss+xml"/><item><title>Goroutine Leaks in Go and How to Prevent Them</title><link>https://rohit-garg.me/goroutine-leak/</link><pubDate>Thu, 30 Apr 2026 10:00:00 +0530</pubDate><guid>https://rohit-garg.me/goroutine-leak/</guid><description>&lt;p>A goroutine leak happens when a goroutine is started, but never gets a realistic path to finish.&lt;/p>
&lt;p>That sounds small because goroutines are cheap. But cheap is not free. A leaked goroutine keeps its stack, references to heap objects, timers, network calls, channel waits, and sometimes file descriptors or database connections alive for longer than intended. One leaked goroutine is usually invisible. One leaked goroutine per request is a production incident waiting patiently.&lt;/p></description></item></channel></rss>