How to find the name of the parent thread?

Question

I know we can have 'parents' and 'children' when we are talking about processes. But is it possible to get parent Thread name?

I did my research, but I have found answer only for .Net

---

Edit: I tried setting names:

public class Main {

    public static void main(String[] args) {
        Thread r = new ThreadA();
        r.start();
    }

}



public class ThreadA extends Thread {
    public void run() {
        Thread.currentThread().setName("Thread A");
        System.out.println("Here  " + Thread.currentThread().getName());
        Thread r = new ThreadB();
        r.setName(Thread.currentThread().getName());
        r.start();
    }
}

public class ThreadB extends Thread {
    public void run() {
        Thread.currentThread().setName("Thread B");
        System.out.println("Here " + Thread.currentThread().getName());
        Thread r = new ThreadC();
        r.setName(Thread.currentThread().getName());
        r.start();
    }
}

public class ThreadC extends Thread {
    public void run() {
        Thread.currentThread().setName("Thread C");
        System.out.println("Here " + Thread.currentThread().getName());
    }
}

Answer 1

I know we can have 'parents' and 'children' when we are talking about processes. But is it possible to get parent Thread name?

A thread does not have a reference to the parent thread so there is no way for you to get the name of the parent from a particular thread. In looking at the code, the parent thread is used to get daemon status, priority, and other information but the name is not stored in the new Thread object.

You mentioned that you need to have the name of the threads so you can group those that "go together in a control flow". I would look into ThreadGroups. They aren't used too often but you might want to in this case:

ThreadGroup threadGroup = new ThreadGroup("mythreadgroup");
Thread thread = new Thread(threadGroup, new Runnable() {...});
...
// then you can do such methods as
threadGroup.enumerate(...);

With thread-groups you can tie multiple threads together. You can, of course, do this with a collection as well yourself.

---

Edit:

You mentioned that the real issue is how can you measure the "time spent" in each component of a distributed system – in this case the RMI handlers.

I'm afraid there is no easy answer here. For wall clock, you are going to have to compare the System.currentTimeMillis() at the start of each RMI method call with the time from the end. You can also use the following code to test the CPU time used by the thread.

ThreadInfo threadInfo =
    ManagementFactory.getThreadMXBean().getThreadCpuTime(thread.getId()); 

To get the "user" time you use getThreadUserTime(...). I'm not sure thread-ids are reused so maybe all you need to do is record all of the thread-ids in your RMI calls in a collection and then note their CPU and user times in a monitoring thread.

I suspect the RMI threads have a particular name so your monitoring thread could find the threads in the thread list to do this but you are not going to be able to determine which thread is handling which RMI request.

Lastly, one thing to consider is to take time stamps at a number of points in the process and to pass this long[] around between calls. This would add some small percentage of data overhead but then you would be able to get a good feeling about the performance of the various different parts of your distributed system.

Answer 2

No - there's no particular concept of a "parent" thread in either Java or .NET. As per the .NET answer you referenced, however, if you're creating the thread yourself you can always give a name which indicates the "creator" thread name within the new thread's name.

EDIT: Your sample code sets the name before it starts... but then overwrites it after it starts, ignoring the previous name.

I'd expect something like:

String currentName = Thread.currentThread.name();
Thread thread = new Thread(new RunnableC());
thread.setName("C (started by" + currentName + ")");
thread.start();

That would be the only place the name of the thread would be set.

Note that this also uses the idea of implementing Runnable rather than extending Thread. That's a separate matter, but is the preferred approach in most cases.

Answer 3

Using InheritableThreadLocal<T> with a carefully crafted

@Override protected T childValue(T parentValue) {
    // Use Thread.currentThread() -- the parent -- to make a return value.
}

makes it possible for threads you have no control over to pass a reference to themselves to any child threads they create -- this will be the closest thing their children have to a parent.

As mentioned by Gray, keeping such references could hinder GC, so wrapping them in a WeakReference<Thread> could be necessary.

Here is an example where each thread knows its full ancestry, unless ancestors are dead and buried by GC.

import java.lang.ref.WeakReference;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.stream.IntStream;

import static java.lang.Thread.currentThread;

public class ThreadAncestry {

    /** Linked list holding the thread which created the current one, and its ancestry */
    static class Chain {

        final Chain ancestors;
        final WeakReference<Thread> parent;

        Chain(Chain ancestors, Thread parent) {
            this.ancestors = ancestors;
            this.parent = new WeakReference<>(parent);
        }

        @Override
        public String toString() {
            Thread parent = this.parent.get();
            return   (parent == null ? "[dead and buried]" : parent.getName())
                   + (ancestors == null ? "" : " -> " + ancestors);
        }

    }

    /** Prints the current thread's ancestry, then spawns a new thread which does the same. */
    static void spawnRecursively(InheritableThreadLocal<Chain> ancestors, int remainingSpawns) {
        System.out.println(  "The ancestors of " + currentThread().getName() + " are " + ancestors.get());
        if (remainingSpawns > 0)
            new Thread(() -> spawnRecursively(ancestors, remainingSpawns - 1)).start();
    }

    /** Uses an InheritableThreadLocal to record the ancestry of each thread as they are created. */
    public static void main(String[] args) {
        InheritableThreadLocal<Chain> ancestors = new InheritableThreadLocal<Chain>() {
            @Override
            protected Chain childValue(Chain parentValue) {
                return new Chain(parentValue, currentThread()); // This is called by the parent thread.
            }
        };

        spawnRecursively(ancestors, 3);

        IntStream.range(0, 6).parallel().forEach(
                i -> System.out.println(  i + " ran on " + currentThread().getName()
                                        + " with ancestors " + ancestors.get()));

        ExecutorService service = Executors.newSingleThreadExecutor();
        service.submit(() -> {
            System.out.println(  currentThread().getName() + " has ancestors "
                               + ancestors.get() + "; it will now attempt to kill these.");
            System.gc(); // May not work on all systems.
            System.out.println(  currentThread().getName() + " now has ancestors "
                               + ancestors.get() + " after attempting to force GC.");
            service.shutdown();
        });
    }

}

This example results in the following output on my machine:

The ancestors of main are null
The ancestors of Thread-0 are main
The ancestors of Thread-1 are Thread-0 -> main
The ancestors of Thread-2 are Thread-1 -> Thread-0 -> main
3 ran on main with ancestors null
4 ran on main with ancestors null
5 ran on ForkJoinPool.commonPool-worker-2 with ancestors main
0 ran on ForkJoinPool.commonPool-worker-3 with ancestors ForkJoinPool.commonPool-worker-1 -> main
1 ran on ForkJoinPool.commonPool-worker-1 with ancestors main
2 ran on ForkJoinPool.commonPool-worker-2 with ancestors main
pool-1-thread-1 has ancestors main; it will now attempt to kill these.
pool-1-thread-1 now has ancestors [dead and buried] after attempting to force GC.

I'm not sure how generally useful this is, but it can be used to, e.g., hierarchically display what each of a number of threads (over which you have no control) have printed to System.out or logged with java.util.Logger; this is something you would want to implement as part of a test framework with parallel test runs, for instance.

Answer 4

In the accepted answer Gray mentions that the thread locals are possibly inherited from a thread that starts another thread (i.e. parent to child; note that the terms "parent" and "child" don't have any more special technical meaning here).

Based on that idea, it seems that there is a way to figure out the parent thread using InheritableThreadLocal: whatever value will be set in the parent (like name) will be available in the child automatically.

---

Moreover, if we don't control the child threads (e.g. we run a third-party component in our thread, and it spawns a few threads, which we wish to keep track of), it might be possible to use this mechanism also. Reflection can let us see other threads' thread locals.

This might allow us to e.g. take a snapshot of all running threads, and figure out which ones were started by our thread, and children of those threads, etc. — all their descendants. Should work well for monitoring purposes. Not sure if it will be any good for anything else.