Skip to content

Trouble understanding Java threads

I learned about multiprocessing from Python and I’m having a bit of trouble understanding Java’s approach. In Python, I can say I want a pool of 4 processes and then send a bunch of work to my program and it’ll work on 4 items at a time. I realized, with Java, I need to use threads to achieve this same task and it seems to be working really really well so far.

But.. unlike in Python, my cpu(s) aren’t getting 100% utilization (they are about 70-80%) and I suspect it’s the way I’m creating threads (code is the same between Python/Java and processes are independent). In Java, I’m not sure how to create one thread so I create a thread for every item in a list I want to process, like this:

    for (int i = 0; i < 500; i++) {
        Runnable task = new MyRunnable(10000000L + i);
        Thread worker = new Thread(task);
        // We can set the name of the thread
        // Start the thread, never call method run() direct
        // Remember the thread for later usage

I took it from here. My question is this the correct way to launch threads or is there a way to have Java itself manage the number of threads so it’s optimal? I want my code to run as fast as possible and I’m trying to understand how to tell and resolve any issues that maybe arising from too many threads being created.

This is not a major issue, just curious to how it works under the Java hood.



Take a look at the Java Executor API. See this article, for example.

Although creating Threads is much ‘cheaper’ than it used to be, creating large numbers of threads (one per runnable as in your example) isn’t the way to go – there’s still an overhead in creating them, and you’ll end up with too much context switching.

The Executor API allows you to create various types of thread pool for executing Runnable tasks, so you can reuse threads, flexibly manage the number that are created, and avoid the overhead of thread-per-runnable.

The Java threading model and the Python threading model (not multiprocessing) are really quite similar, incidentally. There isn’t a Global Interpreter Lock as in Python, so there’s usually less need to fork off multiple processes.