Why C Makes You Manage Memory and Java Doesn't
C hands memory management directly to the programmer through malloc and free; Java's virtual machine takes that job away entirely with a garbage collector.
In C, dynamically allocated memory, anything you get back from malloc, calloc, or realloc, lives on the heap and stays reserved until you explicitly call free on it. There is no runtime tracking how many places in your program still refer to that memory or whether anyone still needs it; the language's model is that the programmer knows when a block is no longer needed and is responsible for saying so. Forget to call free and that memory is leaked for the life of the process; call free and then use the memory anyway, or free it twice, and you get undefined behavior, which is the root of a large share of C's classic bugs.
This is a direct, low-level model. When you malloc some bytes, C's allocator finds a free block of that size, hands you a raw pointer to it, and gets out of the way, no bookkeeping about references, no background process scanning memory, nothing running that you have not explicitly written or called. That is also why C programs can have very predictable, low-overhead memory behavior: there is no garbage collector pause to account for, because there is no garbage collector at all.
Java, by contrast, runs on the JVM, the layer this site's piece on why Java needs a virtual machine covers, and the JVM's garbage collector takes memory management out of your hands almost entirely. When you create an object with new, the JVM allocates it on a managed heap that the garbage collector actively tracks. Once nothing in your running program can still reach an object, no local variable, no field, no entry in a collection references it anymore, the collector reclaims that memory on its own, on its own schedule, without you calling anything equivalent to free.
The trade-off is what you would expect: Java trades some control and some predictability, garbage collection runs on its own schedule and can introduce pauses, for the elimination of an entire category of bugs. Use-after-free, double-free, and most memory leaks caused by forgetting to release something are largely not possible in ordinary Java code, because the language never gives you a raw pointer to free in the first place. C gives you that control back, along with the responsibility that comes with it, which is why systems programming, embedded work, and anything needing tight control over memory layout still reach for C, while application-level code more often reaches for a managed runtime instead.