The 30 second answer
Each thread has its own program counter, its own JVM stack with a frame per method call holding local variables, and a native method stack. All threads share the heap, where every object and array lives and which the garbage collector manages, and the method area, which holds class data and code. In HotSpot since Java 8, class metadata lives in native memory called Metaspace, not in the heap.
From JVMS 2.5:
| Area | Scope | Holds | Error |
|---|---|---|---|
| pc register | per thread | current instruction | none |
| JVM stack | per thread | frames: locals, operand stack | StackOverflowError, or OutOfMemoryError if it can't grow |
| Native method stack | per thread | native calls | same as JVM stack |
| Heap | shared | objects and arrays | OutOfMemoryError: Java heap space |
| Method area | shared | class structures, run-time constant pool, method code | OutOfMemoryError (HotSpot: Metaspace) |
HotSpot specifics: Java 8 removed PermGen and moved class metadata to Metaspace in native memory, limited by -XX:MaxMetaspaceSize (unlimited by default). Interned strings and static field values are on the heap. The process also uses native memory for thread stacks, the code cache, direct ByteBuffers and GC data structures; -XX:NativeMemoryTracking=summary with jcmd <pid> VM.native_memory summary shows the breakdown.
Sources: JVMS 2.5 Run-Time Data Areas, GC Tuning Guide: Other Considerations (Metaspace), Troubleshooting Guide: Diagnostic Tools (Native Memory Tracking)