According to Mike Schilling <mscottschilling@hotmail.com>:
Very like memory leaks and memory corruption (in non-GC'd
environments) in both of those tendencies.
That's the point, actually. Tremendous design efforts went into Java
to make many aspects of programming easier. In particular, the GC is
an automatic system to solve the problem of memory allocation, problem
which proved to be very difficult to tackle by most programmers, even
good programmers, regardless of how "simple" it may look from an
overly theoretical point of view.
The same amount of efforts did not went (yet) into concurrency. Right
now, Java has some primitives ('synchronized' and wait()/notify(),
mostly), which are quite low-level. They are much better than nothing
at all, but I would still classify them at the same "level" than
malloc()/free() with regards to memory allocation. In that view,
Java's support for concurrency is still very "C". You may observe, for
instance, that if you write a multi-threaded application in C, it will
use, for the concurrency part, the same structure than a similar Java
application (you replace synchronized blocks with pthread_mutex_lock()
or EnterCriticalSection(), and wait()/notify() with conditions or
semaphores).
with shared memory. Once again, that's low-level and more a building b,ock