Java threads, carriers, native memory và process services
A Java process contains application, GC, compiler and service threads plus heap and multiple native regions; OS evidence must map to JVM names/IDs/stacks.
JVM Mapping
Platform threads
Java platform Thread is typically wrapper around OS thread; creation allocates native stack/TLS and scheduler task. Thread states are JVM abstractions: RUNNABLE can mean running or blocked in native I/O; WAITING/BLOCKED map imperfectly to OS states.
Virtual threads
Virtual threads are JVM-managed continuations mounted on carrier platform threads. Blocking supported JDK operations unmounts often; pinning/native/foreign calls can occupy carrier. Millions of virtual threads still consume heap/task metadata and can overload DB/socket/downstream; semaphore/rate limits model scarce resources.
JMM vs hardware
Java Memory Model defines happens-before/volatile/locks/final fields, abstracting CPU/compiler reorder. OS scheduling/thread safety does not replace JMM synchronization; data races may show stale/reordered observations allowed by language.
Native memory
Heap, metaspace/class space, code cache, thread stacks, GC structures, direct buffers, JNI/native libs and malloc arenas. NMT tracks JVM categories with overhead but not all native allocations; RSS/PSS/cgroup and heap diagnostics complete picture.
GC/JIT/service threads
Collectors use concurrent/parallel workers; compiler threads consume CPU; reference/finalizer/signal/attach/service threads have roles. CPU spikes or thread count include them. Container processor/memory detection influences GC/pools/heap ergonomics.
Mapping evidence
Use jcmd Thread.print/JFR and OS per-thread CPU. Native IDs may be shown hex in dumps; convert/map carefully. Multiple snapshots correlate hot TID to Java stack; async-profiler/perf need symbols/JIT integration. Avoid one dump conclusion.