Distinguishing between Java threads and OS threads?

How do I distinguish running Java threads and native threads?

In Linux there will be Parent process for every child process, and they say 0 is the parent of all the process, will there be a Parent thread of all the forked Java threads?

How do I know which Java thread is related to OS thread (if a Java thread forkes a native process thread).

Is there any naming convention of Java threads and OS threads?

Can a running Java threads can be suspended or killed from another Java code?

On Linux, Java threads are implemented with native threads, so a Java program using threads is no different from a native program using threads. A "Java thread" is just a thread belonging to a JVM process.

On a modern Linux system (one using NPTL), all threads belonging to a process have the same process ID and parent process ID, but different thread IDs. You can see these IDs by running ps -eLf. The PID column is the process ID, the PPID column is the parent process ID, and the LWP column is the thread (LightWeight Process) ID. The "main" thread has a thread ID that's the same as the process ID, and additional threads will have different thread ID values.

Older Linux systems may use the "linuxthreads" threading implementation, which is not fully POSIX-compliant, instead of NPTL. On a linuxthreads system, threads have different process IDs.

You can check whether your system is using NPTL or linuxthreads by running the system's C library (libc) as a standalone program and looking under "Available extensions" in its output. It should mention either "Native POSIX Threads Library" or linuxthreads. The path to the C library varies from system to system: it may be /lib/libc.so.6, /lib64/libc.so.6 (on 64-bit RedHat-based systems), or something like /lib/x86_64-linux-gnu/libc.so.6 (on modern Debian-based systems such as Ubuntu).

At the OS level, theads don't have names; those exist only within the JVM.

The pthread_kill() C function can be used to send a signal to a specific thread, which you could use to try to kill that specific thread from outside the JVM, but I don't know how the JVM would respond to it. It might just kill the whole JVM.

There is no standard; this completely depends on the Java implementation which you're using. Also, don't mix up "native threads" and "native processes". A process is an isolated entity which can't see into the address space of other processes. A thread is something which runs in the address space of a native process and which can see into the memory of other threads of the same process.

What you see on Linux is something else: Some versions of Linux create an entry in the process table for each thread of a parent process. These "processes" aren't real processes (in the isolation sense). They are threads which can be listed with the ps command. You can find the process which created them by using the parent PID (PPID).

There is no generic solution how Java threads are mapped to OS threads, if at all. Every JVM implementation can do it in a different way.

There is also a pure Java thread implementation, called green threads. This is used as a fallback if native threads aren't supported or the system isn't multithreaded at all. You won't see any green threads at your OS.

> Can a running Java threads can be suspended or killed from another Java code ?

If they are running at the same JVM, yes, with stop(). But that's not a good solution and may work, or not. interrupt() allows the thread so safely shut itself down.

There is no way to kill threads outside of the JVM I know of. If a OS really supports killing of threads, I wouldn't expect the Java application to run correctly afterwards!

> Can a running Java threads can be > suspended or killed from another Java > code ?

In theory yes. In practice, the Thread.kill() and Thread.suspend() methods are deprecated because they are unsafe except in very limited situations. The basic problem is that killing or suspending a Java thread is likely to mess up other threads that depend on it, and shared data structures that it might have been in the middle of updating.

If "another Java code" is meant to mean another JVM, then the chances of it working are even less. Even if you figured out how to send the relevant thread signal, the results are completely unpredictable. My bet is that the "target" JVM would crash.