<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://huncoding.github.io/</id><title>HunCoding</title><subtitle>O blog oficial do canal HunCoding. Conteúdo sobre programação, tecnologia e projetos.</subtitle> <updated>2026-07-06T15:57:26-03:00</updated> <author> <name>Otavio Celestino dos Santos</name> <uri>https://huncoding.github.io/</uri> </author><link rel="self" type="application/atom+xml" href="https://huncoding.github.io/feed.xml"/><link rel="alternate" type="text/html" hreflang="pt-BR" href="https://huncoding.github.io/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Otavio Celestino dos Santos </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>Weak Pointers in Go: Preventing Memory Leaks in Caches with weak.Pointer</title><link href="https://huncoding.github.io/go-weak-pointers-prevent-memory-leaks-cache/" rel="alternate" type="text/html" title="Weak Pointers in Go: Preventing Memory Leaks in Caches with weak.Pointer" /><published>2026-07-06T08:00:00-03:00</published> <updated>2026-07-06T15:57:02-03:00</updated> <id>https://huncoding.github.io/go-weak-pointers-prevent-memory-leaks-cache/</id> <content type="text/html" src="https://huncoding.github.io/go-weak-pointers-prevent-memory-leaks-cache/" /> <author> <name>otavio_celestino</name> </author> <category term="Go" /> <category term="Performance" /> <category term="Memory" /> <summary>Hey everyone! Memory management in in-memory caches has always been a challenge in Go. If you store data in a standard map, such as map[string]*Resource, you are holding strong references to those objects. This means they will never be garbage collected, even if the rest of the application has stopped using them. The new weak package, introduced in the standard library in Go 1.24 and consolid...</summary> </entry> <entry><title>Ponteiros Fracos em Go: Evitando Memory Leaks em Caches com weak.Pointer</title><link href="https://huncoding.github.io/go-ponteiros-fracos-weak-pointer-cache/" rel="alternate" type="text/html" title="Ponteiros Fracos em Go: Evitando Memory Leaks em Caches com weak.Pointer" /><published>2026-07-06T08:00:00-03:00</published> <updated>2026-07-06T15:57:02-03:00</updated> <id>https://huncoding.github.io/go-ponteiros-fracos-weak-pointer-cache/</id> <content type="text/html" src="https://huncoding.github.io/go-ponteiros-fracos-weak-pointer-cache/" /> <author> <name>otavio_celestino</name> </author> <category term="Go" /> <category term="Performance" /> <category term="Memória" /> <summary>E aí, pessoal! Gerenciamento de memória em caches na memória sempre foi um desafio em Go. Se você armazena dados em um mapa padrão, como um map[string]*Resource, você está retendo referências fortes para esses objetos. Isso significa que eles nunca serão coletados pelo Garbage Collector (GC), mesmo que o restante do sistema já tenha parado de usá-los. O novo pacote weak, adicionado na bibliot...</summary> </entry> <entry><title>testing/synctest: The Right Way to Test Concurrent Go Code</title><link href="https://huncoding.github.io/go-synctest-testing-concurrent-code-en/" rel="alternate" type="text/html" title="testing/synctest: The Right Way to Test Concurrent Go Code" /><published>2026-06-07T08:00:00-03:00</published> <updated>2026-07-06T15:57:02-03:00</updated> <id>https://huncoding.github.io/go-synctest-testing-concurrent-code-en/</id> <content type="text/html" src="https://huncoding.github.io/go-synctest-testing-concurrent-code-en/" /> <author> <name>otavio_celestino</name> </author> <category term="Go" /> <category term="Testing" /> <category term="Concurrency" /> <summary>Hey everyone! Testing concurrent code in Go has always been uncomfortable. You write a goroutine, and suddenly your test needs a time.Sleep to wait for it. Then the sleep is too short on a slow CI machine and the test flakes. You add more sleep. Now the test suite takes forever. The testing/synctest package, stable since Go 1.25, solves exactly this. It gives you a controlled environment wher...</summary> </entry> <entry><title>testing/synctest: O Jeito Certo de Testar Código Concorrente em Go</title><link href="https://huncoding.github.io/go-synctest-testando-codigo-concorrente/" rel="alternate" type="text/html" title="testing/synctest: O Jeito Certo de Testar Código Concorrente em Go" /><published>2026-06-07T08:00:00-03:00</published> <updated>2026-07-06T15:57:02-03:00</updated> <id>https://huncoding.github.io/go-synctest-testando-codigo-concorrente/</id> <content type="text/html" src="https://huncoding.github.io/go-synctest-testando-codigo-concorrente/" /> <author> <name>otavio_celestino</name> </author> <category term="Go" /> <category term="Testing" /> <category term="Concurrency" /> <summary>E aí, pessoal! Testar código concorrente em Go sempre foi chato. Você escreve uma goroutine, e de repente o teste precisa de um time.Sleep pra esperar ela terminar. O sleep é curto demais na máquina lenta do CI e o teste flake. Você aumenta o sleep. Agora a suite demora pra caramba. O pacote testing/synctest, estável desde o Go 1.25, resolve exatamente isso. Ele te dá um ambiente controlado o...</summary> </entry> <entry><title>GOMAXPROCS e Kubernetes: o problema que todo mundo tinha e ninguém sabia</title><link href="https://huncoding.github.io/gomaxprocs-kubernetes-problema/" rel="alternate" type="text/html" title="GOMAXPROCS e Kubernetes: o problema que todo mundo tinha e ninguém sabia" /><published>2026-05-14T08:00:00-03:00</published> <updated>2026-07-06T15:57:02-03:00</updated> <id>https://huncoding.github.io/gomaxprocs-kubernetes-problema/</id> <content type="text/html" src="https://huncoding.github.io/gomaxprocs-kubernetes-problema/" /> <author> <name>otavio_celestino</name> </author> <category term="Go" /> <category term="Kubernetes" /> <category term="Performance" /> <summary>E aí, pessoal! Você já olhou para um dashboard de Kubernetes, viu CPU usage tranquila, latência subindo, p99 explodindo, e não entendeu nada? Esse é um daqueles problemas que existe em quase toda aplicação Go rodando em Kubernetes, mas que raramente aparece nos runbooks. O pod não está consumindo CPU demais. Não está sem memória. Está sendo “throttled” pelo kernel, e o motivo é que o runtime ...</summary> </entry> </feed>
