Java Academy · Lesson

When Parallelism Helps

Workload and data size factors.

When Parallelism Helps is a free Java Academy lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Java Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Parallelism Has a Cost

Going parallel adds overhead: splitting data, dispatching tasks, and merging results. It only pays off when that cost is smaller than the time saved.

import java.util.stream.IntStream;

public class Main {
    public static void main(String[] args) {
        long sum = IntStream.rangeClosed(1, 10_000_000)
            .parallel()
            .asLongStream()
            .sum();
        System.out.println(sum);
    }
}

Factor 1: Data Size (N)

Large N amortizes the fixed overhead of parallelism. A rough rule of thumb is tens of thousands of elements before parallel becomes worthwhile.

import java.util.stream.IntStream;

public class Main {
    public static void main(String[] args) {
        long count = IntStream.rangeClosed(1, 5_000_000)
            .parallel()
            .filter(n -> n % 7 == 0)
            .count();
        System.out.println(count);
    }
}

Factor 2: Work Per Element (Q)

The cost Q of processing each element matters. Expensive per-element work (heavy computation) benefits from parallelism even at smaller N.

import java.util.stream.IntStream;

public class Main {
    public static void main(String[] args) {
        long primes = IntStream.rangeClosed(2, 200_000)
            .parallel()
            .filter(Main::isPrime)
            .count();
        System.out.println(primes);
    }

    static boolean isPrime(int n) {
        for (int i = 2; (long) i * i <= n; i++)
            if (n % i == 0) return false;
        return true;
    }
}

The N times Q Intuition

Think of total useful work as N x Q. The larger that product, the more parallelism can help. Tiny N or trivial Q rarely justifies it.

import java.util.stream.IntStream;

public class Main {
    public static void main(String[] args) {
        double sum = IntStream.rangeClosed(1, 1_000_000)
            .parallel()
            .mapToDouble(n -> Math.sqrt(n) * Math.log(n + 1))
            .sum();
        System.out.println(sum);
    }
}

Factor 3: Splittability

Data sources that split cheaply and evenly parallelize well: arrays, ArrayList, and IntStream.range. LinkedList and iterator-based sources split poorly.

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<Integer> list = new ArrayList<>();
        for (int i = 0; i < 1_000_000; i++) list.add(i);
        long even = list.parallelStream().filter(n -> n % 2 == 0).count();
        System.out.println(even);
    }
}

Good Source: Arrays and Ranges

Primitive ranges have known size and split in O(1), making them ideal parallel sources.

import java.util.stream.LongStream;

public class Main {
    public static void main(String[] args) {
        long sum = LongStream.rangeClosed(1, 20_000_000)
            .parallel()
            .sum();
        System.out.println(sum);
    }
}

Poor Source: Iterative Generators

Stream.iterate produces elements sequentially by definition, so it cannot split until elements are realized. It is a weak parallel source.

import java.util.stream.Stream;

public class Main {
    public static void main(String[] args) {
        long count = Stream.iterate(1, n -> n + 1)
            .limit(1_000_000)
            .parallel()
            .filter(n -> n % 2 == 0)
            .count();
        System.out.println(count);
    }
}

Factor 4: Cheap Merge Step

Parallelism needs an inexpensive way to combine partial results. sum and count merge trivially; building a sorted list or a tree-heavy collector merges expensively.

import java.util.stream.IntStream;

public class Main {
    public static void main(String[] args) {
        int max = IntStream.rangeClosed(1, 5_000_000)
            .parallel()
            .map(n -> n % 1000)
            .max()
            .getAsInt();
        System.out.println(max);
    }
}

Avoid for I/O-Bound Work

Parallel streams target CPU-bound tasks on the fork-join pool. Blocking I/O starves the shared pool and hurts the whole application. Use dedicated executors for I/O instead.

import java.util.stream.IntStream;

public class Main {
    public static void main(String[] args) {
        long total = IntStream.rangeClosed(1, 1_000_000)
            .parallel()
            .mapToLong(n -> (long) n * n)
            .sum();
        System.out.println(total);
    }
}

Measure, Do Not Guess

The only reliable way to know if parallel helps is to benchmark with realistic data. Intuition about performance is frequently wrong.

import java.util.stream.LongStream;

public class Main {
    public static void main(String[] args) {
        long start = System.nanoTime();
        long sum = LongStream.rangeClosed(1, 50_000_000).parallel().sum();
        long ms = (System.nanoTime() - start) / 1_000_000;
        System.out.println("sum=" + sum + " took ~" + ms + "ms");
    }
}

A Practical Checklist

Favor parallel when all hold:

Large N and/or expensive per-element work.
A splittable source (array, ArrayList, range).
A cheap, associative merge.
CPU-bound, no blocking I/O.

import java.util.stream.IntStream;

public class Main {
    public static void main(String[] args) {
        double avg = IntStream.rangeClosed(1, 10_000_000)
            .parallel()
            .mapToDouble(Math::sqrt)
            .average()
            .getAsDouble();
        System.out.println(avg);
    }
}

Quick Check

Which scenario is the best candidate for a parallel stream?

Recap

You learned when parallelism helps:

Benefit grows with N x Q (data size times per-element cost).
Need a splittable source (arrays, ArrayList, ranges).
Need a cheap associative merge.
Keep it CPU-bound, avoid blocking I/O, and always measure.

Frequently asked questions

Is the “When Parallelism Helps” lesson free?

Yes — the full text of “When Parallelism Helps” is free to read here on the web, and the Java Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Java Academy course, upgrade to CoddyKit PRO.

What will I learn in “When Parallelism Helps”?

Workload and data size factors. You practise Java Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Java Academy?

No prior experience is required. Java Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “When Parallelism Helps” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Java Academy lesson?

Yes. Every Java Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to Java Academy