Can this thread be alive and how to use java.lang.Thread.join() method

Question

I have read some SO question and docs before but do not find my response :

• How long a thread will be alive in java?
• When is a Java thread alive?
• http://journals.ecs.soton.ac.uk/java/tutorial/java/threads/states.html

So...

public class MyThread extends Thread {
  public MyThread() {
    this.setName("MyThread-" + System.currentTimeMillis());
    this.start();
  }

  public MyThread(long millis) throws InterruptedException {
    this.setName("MyThread-" + System.currentTimeMillis());
    this.join(millis);
    this.start();
  }

  @Override
  public void run() {
    System.out.println("I am running...");
    // This thread does not sleep... no Thread.sleep() in run method.
    // Do some things like requesting a database
    // Database response happens in less time that the timeout
  }
}

public class MyClass {

  public MyClass(){
    for (int i = 0; i < 5; i++) {
      Thread t1 = new MyThread();
      t1.join(5000);
      if (t1.isAlive()) {
        System.out.println("I'm alive");
        // do some things
      } else {
        System.out.println("I'm not alive");
      }

      Thread t2 = new MyThread(5000);
      if (t2.isAlive()) {
        System.out.println("I'm alive");
        // do some things
      } else {
        System.out.println("I'm not alive");
      }

    }
  }
}

It seems it can not be but could one of the t1 be alive ? What about t2 ? What happend when I call join() after start()

For information, I am using :

• JVM: Java HotSpot(TM) Client VM (20.45-b01, mixed mode, sharing)
• Java: version 1.6.0_45, vendor Sun Microsystems Inc.

Update after reading some of your responses

If I understand, a better implementation would be something like :

public class MyThread extends Thread {
  public MyThread() {
    super("MyThread-" + System.currentTimeMillis());
  }

  @Override
  public void run() {
    System.out.println("I am running...");
    // This thread does not sleep... no Thread.sleep() in run method.
    // Do some things like requesting a database
    // Database response happens in less time that the timeout
  }
}

public class MyClass {

  public MyClass(){
    for (int i = 0; i < 5; i++) {
      Thread t1 = new MyThread();
      t1.start();
      t1.join(5000);

      if (t1.isAlive()) {
        System.out.println("I'm alive");
        // do some things
      } else {
        System.out.println("I'm not alive");
      }
    }
  }
}

Both responses have helped me a lot : https://stackoverflow.com/a/29775219/1312547 and https://stackoverflow.com/a/29775083/1312547

Answer 1

The documentation of isAlive() says:

A thread is alive if it has been started and has not yet died.

The documentation of join() says:

Waits at most millis milliseconds for this thread to die

So, after join() returns,

• either the thread has died, and isAlive() will be false
• or the thread has not died yet but the delay has elapsed, and isAlive() could be true. That is possible, but is extremely unlikely, given that the thread has 5 seconds to do its simple job of printing to the console.

Answer 2

Notice that although the (JDK 7) documentation for Thread.join(long) says

Waits at most millis milliseconds for this thread to die.

It also continues with

This implementation uses a loop of this.wait calls conditioned on this.isAlive.

And Thread.isAlive says:

A thread is alive if it has been started and has not yet died.

So with your code:

• When calling t1.isAlive(), it is always false since you joined after starting the thread (from the constructor).
• When calling t2.isAlive(), it is most of the time true since
  • you joined before starting the thread (in the constructor), which returns immediately
  • the thread has just started (in the constructor)

So to answer your question

It seems it can not be but could one of the t1 be alive ?

For t1, no, as long as you wait more than the time it takes it to run. For t2, yes.

Answer 3

Your t1.isAlive() will always be false. The thread you are executing takes a millisecond to run. You are calling t1.join(5000) which joins that thread with the current thread once it dies. Since it always runs quicker than 5 seconds then it is always dead by the time it reaches your check for whether it is alive or not.

Your t2.isAlive() will always be true. On the t2 thread you are calling join in the constructor before you call the start method. Since a thread is always dead until the start method is called that join in the constructor returns immediately. Which then allows start to be called. Even though start is called on a thread it does not mean that it executes right away. It just marks it as available for execution and the thread scheduler will start it up at some point in the future. Since you call t2.isAlive() immediately after the constructor it will always be true since the current thread won't be swapped out yet.

Answer 4

With your code, t1 threads will certainly always print "I'm not alive", and t2, "I'm alive".

For t2 threads, it is weird to call this.join(...) before starting the thread, since (as a complement to what @JB pointed out), the join() doc says

This implementation uses a loop of this.wait calls conditioned on this.isAlive.

And, since the thread is not started yet, the join has no effect and returns immediately.

But your question is on what can make t1 alive. Just add a Thread.sleep(6000) in the run() method, and you will see the thread as alive. It means that if the task (DB request, ...) done by the thread is longer than the timeout set in the join(), then the answer is "yes, t1 can be alive".