1

Look at the codes below, it always shows "Main Thread Done".

    private static class Person{
        private String name;
    }

    public static void main(String[] args) throws InterruptedException {
        final Person person = new Person();

        new Thread(()->{

            System.out.println("new Thread Done");
            //person.name = "Jack";

        }).start();


        //person.name = "Tom";

        System.out.println("Main Thread Done");


        //System.out.println(person.name);
    }

My question is, why does the main thread always run faster than new thread? Is it possible for result "new Thread Done"? I've tried on Windows, CentOS, macOS, both "Main Thread Done". I didn't find any documents said that main thread in java always faster than any others.

longslee
  • 31
  • 4
  • It takes time to start a thread, so you're not doing a fair comparison – Ted Klein Bergman Sep 07 '20 at 09:14
  • The way I see it, and I might be wrong, is that although both threads seem to do the same thing, one needs to account on the overhead of creating a new thread. The creation of a new thread isn't exactly instantaneous, the JVM at some point will need to ask the OS for a new thread to use, and that can take time. – npinti Sep 07 '20 at 09:14
  • 2
    I closed as DUP to a different question, as the underlying point is: the code you are showing here doesn't do proper measuring. The numbers that come out of such a naive approach ... simply can't be trusted. Note for example that alone these calls to out.printl() need considerable amount of time ... which cant be predicted. The basic answer is: threads run "at the same speed", and unless you can show a real benchmark that proves vastly different execution times I simply think: you are hunting ghosts here. – GhostCat Sep 07 '20 at 09:26
  • 1
    IMO, you are asking the wrong question You should be asking why the main thread _prints sooner_ than the new thread. The words, "prints sooner" describe the evidence that you see before your eyes. The words, "runs faster" describe your incorrect conclusion about what the evidence means. – Solomon Slow Sep 07 '20 at 12:26

1 Answers1

0

The main thread is starting first spinning out a thread which needs to spin up then moving on to its print statement. While the second thread is spinning up the first is completing. It's faster because it started first. Then the second thread (in the original code, before edit) is wrapped in a try statement which adds a little overhead.

As others have said though, it wont always complete in this order but you're probably seeing it execute in this order semi-reliably when run on the same system in the same state because of the above.

Ross Drew
  • 8,163
  • 2
  • 41
  • 53
  • Threads are not processes. So it is not "spinning out a process". – Mark Rotteveel Sep 07 '20 at 09:15
  • nitpicky, but ok – Ross Drew Sep 07 '20 at 09:16
  • 1
    The real point is: the above code is absolutely not a valid benchmark. Period. Any observed duration or order of print statements is mostly "random". It can be very different the next time. Alone "printing" carries quite a bit of runtime cost. In other words: when you do random things, and measure poorly, the results arent worth "explaining". – GhostCat Sep 07 '20 at 09:28
  • I'm sorry , sleep(0) just give a chance for others, the original code wtihout sleep and try statement. – longslee Sep 07 '20 at 09:45
  • The question isn't "is this a valid benchmark", it's why does this -for me- always complete in the same order. In this case it may be random but it's not observed as random and likely because of what I explained. I've added an addendum to be sure that it *is* random but this is still not a question on benchmarking. – Ross Drew Sep 07 '20 at 10:52
  • @GhostCat I doubt that the "runtime cost" of "printing" has any relevance in this case. The `System.out` stream is protected by a mutex. To answer which thread will "print" first, one merely needs to ask which thread will be first to lock the mutex. – Solomon Slow Sep 07 '20 at 12:29
  • The point is: the exact duration of printing might vary dramatically from one call to the next. Therefore including print statements always adds significant inaccuracy, especially when the other operations that get measured are basically "no ops". – GhostCat Sep 07 '20 at 12:32
  • There is no "next" call in this case. Each thread prints just one line. By the time either one of them begins to print, the race is already over. – Solomon Slow Sep 07 '20 at 12:33
  • As you commented above: the OP is talking about "runtime". And that implies that maybe he also tried to time execution time. Or that some future reader comes in, and is looking for information about execution time, but in a slightly different context. – GhostCat Sep 07 '20 at 12:37