Search code examples
javalinuxmultithreadingblocking

Java Threads, Blocking I/O, and Scheduling

The Scenario below is simplified

Server is a 4 Core Intel (no hyperthreading) Linux Server, Java 11 Server 64 VM. We have a ThreadPoolExecutor with a maxSize of 15 Threads.

One method using the Executor submits 4 Callables that do long running database calls, another method uses the Executor to submit 10 more that do very fast calculations. The first 4 Threads get CPU time and then Block awaiting queries to return. My question is two fold - are the DB calls similar to Blocking I/O and when new Callables are submitted and assigned threads will those threads start running while the other threads are waiting on the DB calls to return, or will they be queued? I know there are many variables I am not covering here, point them out if they are pertinent, but I think the base question is pretty clear.

Solution

  • are the DB calls similar to Blocking I/O

    Yes, calls involving JDBC block, thereby pausing the host OS thread underlying a Java thread. At least currently, in Java 11, and in Java 17 & 20.

    This fact may change if Project Loom succeeds.

    when new Callables are submitted and assigned threads will those threads start running while the other threads are waiting on the DB calls to return, or will they be queued?

    If all of the threads in the thread pool backing your executor service are blocked, or are otherwise busy/occupied, pending tasks are queued as are any more submitted tasks. This queueing is the main job of an executor service.

    Again, Project Loom with its virtual threads (technically, fibers) aims to alter this situation.

    Server is a 4 Core Intel (no hyperthreading) … a maxSize of 15 Threads

    Do you suspect your shorter simply calls are piling up behind your long blocking database calls that hog all the threads? Like some small fast commuter cars stuck behind a convoy of big slow semi-trailer trucks on a highway?

    If so, consider instantiating two executor services.

    • Dedicate one executor service to the long-blocking database calls (the big slow semi-trailer trucks).
    • Dedicate the other executor service as an “express lane” for all the other shorter simpler calls (the small fast commuter cars).

    Let me stress that future readers of this Answer should check for updates on the progress of Project Loom after Java 20. The calculus of how to manage threading will change dramatically.