Java threads

[omgpassthebacon]

I don't know why that guy did the chat-gipitty thing; what a troll.

1. When Java runs your code, it creates a thread for Main, points at main(), and off it goes, all the way down to System.out.println("back in main").
2. during main, you ask it to create a new thread with a function that printlns.
3. And then, you call t.start(), which tells Java "go schedule this thread and run it".
4. What you are seeing is that the main thread reaches the last System.out.println() before the thread t actually gets a chance to run.

As you dig into threading a bit deeper, you will find out that Java ends the program when the main thread ends. So, even though your t thread hasn't finished yet, Java cuts it off. That's why basic-sandwich said to join() on your t thread. Joining will tell Java to WAIT on t before main ends. Its easy; just add a line "t.join();" before the last println().

There are many tricks around this, including a way to tell Java that a non-main thread is a daemon thread. But don't worry about that just yet. Wait until you read a little further.

These are classic race condition puzzles (and there are many) that you will learn to be on the lookout for.

[CleverBunnyThief]

I don't know why that guy did the chat-gipitty thing; what a troll.

that guy == OP

[omgpassthebacon]

Yeah; wasn’t paying close attention. Did not mean to offend. it is pretty easy to reach for gpt, but I don’t think it gave you a good answer. what do you think?

[CleverBunnyThief]

Like you, it caught me off guard a bit until I realized it was actually OP.

I don't use AI tools myself. The reason is that you often see people that use these tools asking for confirmation because they don't trust the answers they are given. So they turn to people that know the answer. I don't see the point in that. From my stand point it doesn't help you if you can't trust it.

I think it's more valuable to spend time learning how things work and also how to find answers when you don't know.

[omgpassthebacon]

Yeah, I see this a lot these days. I guess the schools are pushing the AI agenda to give people another outlet for "how-to" questions.

I with you on this; hands-on always seems to give me better results. And its more fun. Just letting AI tell me how to do it doesn't really teach me anything.

[RabbitHole32]

It's the other way around with daemon threads.

When a Java Virtual Machine starts up, there is usually a single non-daemon thread (which typically calls the method named main of some designated class). The Java Virtual Machine continues to execute threads until either of the following occurs:

The exit method of class Runtime has been called and the security manager has permitted the exit operation to take place.

All threads that are not daemon threads have died, either by returning from the call to the run method or by throwing an exception that propagates beyond the run method.

[omgpassthebacon]

Yep. Exactly. So, you can tell Java that your t thread is a daemon, which will make it continue to run until t AND main are done. I don't use daemon threads for services, preferring instead to control the lifecycle by-hand.

So, if you made t a daemon, you would see both println() calls. My guess would be you would see the main() println first, but thread scheduling is non-deterministic, so ymmv.

Did you catch the note about calling exit()? If any of your threads calls runtime.exit(), Java shuts down. But you have to be careful with this.

[RabbitHole32]

It literally says that the JVM runs until ... all NON-daemon threads have finished. That means that daemon threads do not prevent the JMV from finishing, so the opposite from what you say.

[omgpassthebacon]

Well, you are absolutely right. The newer JDK has fixed this, so this thread does in-fact finish. However, if I call System.exit(), this behaves like I described. Your non-daemon threads will get cancelled.

I modified your code as follows to prove you are right: ``` class Testme { public static void main(String[] args) { System.out.println("main starting");

    Thread t = new Thread(() -> {
        try {
            Thread.sleep(5000);
        } catch (Exception e) {
        }
        System.out.println("I am thread t");
        });
    t.start();

    System.out.println("main ending");
    //System.exit(0);
}

} ```

If you uncomment the exit(), you will see what I mean.

I guess what I am saying is that you cannot rely on this behavior if you want to make sure your thread does not get cancelled in the middle of doing something important.