What should I know about garbage collection as a Java developer?
One thing that that I hadn&#x27;t fully understood until recently is that garbage collectors can actually allow you to write <i>more efficient</i> code.<p>Previously, I had the general understanding that you were trading convenience (not thinking about memory management or dealing with the related bugs) in exchange for performance (GC slows your program down).<p>That&#x27;s still true broadly, but there&#x27;s an interesting class of algorithms where GC can give you a perf. improvement: immutable data structures, typically used in high-concurrency situations.<p>Consider a concurrent hash map: when you add a new key, the old revision of the map is left unchanged (so other threads can keep reading from it), and your additions create a new revision. Each revision of the map is immutable, and your &quot;changes&quot; to it are really creating new, immutable copies (with tricks, to stay efficient).<p>These data structures are great for concurrent performance, but there&#x27;s a problem: how do you know when to clean up the memory? That is: how do you know when all users are done with the old revisions, and they should be freed?<p>Using something like a reference count adds contention to this high-concurrency data structure, slowing it down. Threads have to fight over updating that counter, so you have now introduced shared mutable state which was the whole thing you were trying to avoid.<p>But if there&#x27;s a GC, you don&#x27;t have to think about it. And the GC can choose a &quot;good time&quot; to do it&#x27;s bookkeeping in bulk, rather than making all of your concurrent accesses pay a price. So, if done properly, it&#x27;s an overall performance win.<p>Interestingly, a performant solution without using GC is &quot;hazard pointers,&quot; which are essentially like adding a teeny tiny garbage collector, devoted just to that datastructure (concurrent map, or whatever).