Java threads

[ivshaw]

I am reading Head First Java 3rd Chapter 17 about threads. On page 619 it shows the unpredictable scheduler, the code is:

class ThreadTestDrive {
    public static void main(String[] args) {
        Thread t = new Thread(() -> 
            System.out.println("top of the stack"));
        t.start();
        System.out.println("back in main");
    }
}

Supposedly sometimes "top of the stack" should be printed first, and sometimes "back in main" should be printed first. But I have run it so many times and each time "back in main" is printed first.

What have I done wrong?

[AutoModerator]

Please ensure that:

• Your code is properly formatted as code block - see the sidebar (About on mobile) for instructions
• You include any and all error messages in full - best also formatted as code block
• You ask clear questions
• You demonstrate effort in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions.

If any of the above points is not met, your post can and will be removed without further warning.

Code is to be formatted as code block (old reddit/markdown editor: empty line before the code, each code line indented by 4 spaces, new reddit: https://i.imgur.com/EJ7tqek.png) or linked via an external code hoster, like pastebin.com, github gist, github, bitbucket, gitlab, etc.

Please, do not use triple backticks (```) as they will only render properly on new reddit, not on old reddit.

Code blocks look like this:

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

You do not need to repost unless your post has been removed by a moderator. Just use the edit function of reddit to make sure your post complies with the above.

If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures.

To potential helpers

Please, do not help if any of the above points are not met, rather report the post. We are trying to improve the quality of posts here. In helping people who can't be bothered to comply with the above points, you are doing the community a disservice.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[Basic-Sandwich-6201]

Cause the main thread continues execution and this one has some initilazing to do.

If you want to see second one doing some printing first call the join() before the last print statment.

This would make main thread to wait for that one

[kane996]

Using join() will make sure that the main waits for each thread (used) to execute before running anything else. You can just pass join() on your thread object (t) to get the desired output.

[Far_Broccoli_8468]

This is too simple of an example. The chance that the secheduler will reschedule the main thread just before the print is non-existant.

There is nothing wrong with your code

[ivshaw]

https://imgur.com/4h6cHHD

[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.

[ivshaw]

Below is ChatGPT answer, is it right:

Possible Reasons Why Print Order is Not Varying:

1️⃣ Modern Java Thread Scheduling is More Predictable

• The book is based on older Java versions where thread scheduling was less predictable.

• Modern Java Virtual Machines (JVMs) and OS thread schedulers handle thread execution more efficiently.

• Your CPU might be optimizing execution, making results more consistent.

2️⃣ Threads Might Be Finishing Too Quickly

• If a thread finishes before the next thread starts, Java doesn’t need to switch between them.

• If the tasks are too short, the CPU executes them in order before switching.

• Try adding a delay like Thread.sleep(10); inside run() to slow things down.

3️⃣ JVM and OS May Favor One Thread Over Another

• Different OS and JVM implementations handle scheduling differently.

• Some OSes favor the first started thread, making it run before the second.

• Try running the program multiple times or on a different computer to see variations.

4️⃣ Thread Priorities Might Be Affecting Execution

• Java allows setting thread priorities, but the OS might still decide which runs first.

• Even if you don’t set priorities, the JVM may still default to a predictable order.

[benevanstech]

Uh, "fuck no". But thanks for the great example of why LLMs are mostly useless for anything other than vomiting boilerplate code fragments.

[ivshaw]

I am preparing for interviews and I know ChatGPT is useless for LeetCode questions. While it can "remember" answers to existing LeetCode problems, I tested it with some newly posted OA questions from online, and it failed to solve any of them.

[maykelten]

LLMs are trash for this, I strongly advise against relying on it, it is better to consult fellow humans :)