ExecutorService adding delay

Question

I have a very simple program which uses ExecutorService.

I have set the no. of threads to 4, but the time taken is same as that set to 2.

Below is my code:

public class Test {
     private static final Logger LOGGER = Logger.getLogger("./sample1.log");

    @SuppressWarnings("unchecked")
    public static void main(String[] args) throws Throwable {
        ExecutorService service = Executors.newFixedThreadPool(4);
        Future<String> resultFirst = service.submit(new FirstRequest());
        Future<String> resultSecond = service.submit(new SecondRequest());
        Future<String> resultThird = service.submit(new ThirdRequest());
        Future<String> resultFourth = service.submit(new FourthRequest());

        String temp1 = resultSecond.get();
        temp1 = temp1.replace("Users", "UsersAppend1");

        String temp2 = resultThird.get();
        temp2 = temp2.replace("Users", "UsersAppend2");

        String temp3 = resultFourth.get();
        temp3 = temp3.replace("Users", "UsersAppend3");

        //System.out.println(resultFirst.get() + temp1 + temp2 + temp3);
        //LOGGER.info("Logger Name: "+LOGGER.getName());

        LOGGER.info(resultFirst.get() + temp1 + temp2 + temp3);

        service.shutdownNow();
        service.awaitTermination(10, TimeUnit.SECONDS);

        System.exit(0);
        }
}

Here FirstRequest, SecondRequest, ThirdRequest and FourthRequest are different classes which calls another class which is common to all.

I have created distinct objects for the common class so I don't think it's a case of deadlock/Starvation.

Answer 1

You want to start here - meaning: it is actually hard to measure Java execution times in a reasonable way. Chances are that you have an over-simplified view; and thus your measurements aren't telling anything.

And beyond that: you have to understand that "more threads" do not magically reduce overall runtime. It very much depends on what you are doing; and how often for example your threads spend time waiting for IO.

Meaning: "adding" threads only helps when each thread is inactive for "longer" periods of time. When each thread is constantly burning CPU cycles at 100% ... then more threads do not help; to the contrary: then times get worse, because the only thing you do is add overhead for setting up and switching between your tasks.

Answer 2

How many processors do you have ? Time taken depends upon type of task you are performing, type of resources you are using in your tasks etc. Adding more threads doesn't mean your process will become fast, it just mean that if there are idle processing power available, then java will try to use them.

Answer 3

I have set the no. of threads to 4, but the time taken is same as that set to 2.

This is a very common issue. I've heard of countless times that sometimes works really hard to turn a single-threaded application into a multi-threaded application so find that it doesn't run faster. It actually can run slower because of thread overhead and refactoring issues.

The analogy is a overworked researcher on a project. You could divide their work and give it to 4 graduate students to work concurrently but if they all have to ask the researcher questions all of the time then the project isn't going to go any faster and the lack of coordination between the 4 graduate students can make the project take even longer.

The only times adding additional threads to an application will definitively improve the throughput is when the threads are:

1. completely independent – i.e. not sharing data (or not a lot) between threads which is when they block or have to synchronize memory
2. completely CPU bound – i.e. doing only data processing and not waiting on disk or network IO or other system resources
3. able to make use of additional system CPUs

Here FirstRequest, SecondRequest, ThirdRequest and FourthRequest are different classes which calls another class which is common to all.

Right, this is a red flag. The First/Second/... Request classes may be able to work concurrently but if they have to call synchronized blocks in the common class then they will block each other. One of the tricky things with threaded programming is how to limit the data sharing while still accomplishing their tasks. If you show more of the common class then we might be able to help you more.

The other big red flag is any amount of IO. Watch out for reading and writing to disk or network. Watch also for logging or other output. It is often efficient to have one thread reading from disk, a number of threads processing what is read, and one thread writing. But even then, if the processing isn't very CPU intensive, you might see little to no speed improvement because the speed of the application is limited by the IO bandwidth of the disk device.

Web applications that spawn a thread for every request to be handled can be efficient because they are handling so many network IO bound requests simultaneously. But the real win is the code improvements that come from the thread being able to concentrate on its request and the thread subsystems will then take care of the context switching between requests when the thread is blocked waiting on network or disk IO.