Java For Loop — i-- Termination Bug Kills Batch Jobs

Almost every real program needs to repeat something. A banking app applies interest to thousands of accounts. A game redraws the screen 60 times per second. A search engine scores millions of web pages.

The for loop solves this elegantly. It lets you write an action once and tell Java exactly how many times to run it. It also keeps a counter variable automatically, so you always know which repetition you are on.

By the end of this article you will understand every part of a for loop's syntax, be able to write one from scratch without looking anything up, know how to loop through arrays correctly, nest one loop inside another without blowing up your performance budget, and spot the mistakes that trip up nearly every beginner — including a few that produce no compile error at all, which makes them genuinely dangerous.

These are not academic exercises. Every example here reflects something you will write in real production code within your first few months of Java development.

What a Java For Loop Actually Guarantees (and Doesn't)

A Java for loop is a control structure that repeats a block of code based on a boolean condition evaluated before each iteration. Its syntax — for (initialization; termination; increment) — bundles three operations: a one-time setup, a pre-iteration check, and a post-iteration step. The loop terminates when the termination expression evaluates to false. This is not syntactic sugar for a while loop; the increment clause executes after the body, not before, which matters when the increment itself has side effects.

The termination condition is checked at the top of each iteration. If it's false initially, the body never runs — zero iterations. The increment expression (e.g., i++ or i--) runs after the body completes, then control returns to the condition. This ordering is fixed: body, then increment, then condition. A common mistake is assuming i-- in the increment clause decrements before the condition check — it doesn't. That misunderstanding causes off-by-one errors and infinite loops in production batch jobs.

Use a for loop when the number of iterations is known or bounded, and you need a clear, self-contained iteration contract. It's the right choice for iterating over arrays, lists, or any range where the loop variable's lifecycle is local to the loop. In high-throughput systems, the for loop's predictable overhead (O(n) iterations, constant per-iteration cost) makes it suitable for tight loops processing thousands of records per second — provided the termination condition is rock-solid.

Anatomy of a Java for Loop — What Each Part Actually Does

A for loop has three parts crammed into one line, separated by semicolons. Each part has a specific job, and understanding each job separately makes the whole thing click immediately.

The first part is the initializer. It runs exactly once — right before the loop starts. You use it to create and set your counter variable. Think of it as setting the odometer to zero before a road trip. It runs once, establishes your starting position, and then stays out of the way.

The second part is the condition. Java checks this before every single repetition, including the very first one. If it evaluates to true, the loop body runs. If it evaluates to false, the loop stops immediately and Java moves on to whatever comes after the closing brace. This is the gatekeeper — it controls entry, not exit.

The third part is the update. It runs after every repetition of the loop body — right before the condition is checked again. You use it to change your counter so that the loop eventually ends. If you get this wrong, you get an infinite loop. If you leave it out entirely, same result.

The execution order is fixed and worth memorizing: initializer runs once → condition checked → body runs if true → update runs → condition checked again → repeat. That cycle continues until the condition is false.

One detail that catches people off guard: the condition is checked one more time than the body executes. A loop that runs 10 times checks its condition 11 times — once for each successful iteration, and once more when it evaluates to false and the loop exits. This is normally invisible, but if your condition calls a method with side effects, that method runs 11 times, not 10.

public class BirthdayInvitations {
    public static void main(String[] args) {

        // We need to write 5 birthday invitations.
        // The for loop handles the counting automatically.
        //
        // Part 1 — int invitationNumber = 1
        //   Creates the counter and starts it at 1.
        //   Runs exactly ONCE, before the loop begins. Never again.
        //
        // Part 2 — invitationNumber <= 5
        //   Checked before EVERY iteration, including the first.
        //   When invitationNumber reaches 6, this is false and the loop exits.
        //   The loop body never sees invitationNumber = 6.
        //
        // Part 3 — invitationNumber++
        //   Runs AFTER every iteration of the body.
        //   invitationNumber++ is shorthand for invitationNumber = invitationNumber + 1.
        //   This is what moves the counter toward the stopping condition.

        for (int invitationNumber = 1; invitationNumber <= 5; invitationNumber++) {
            System.out.println("Writing invitation #" + invitationNumber);
        }

        // This line runs AFTER the loop finishes.
        // The loop ending does not affect code outside the loop block.
        System.out.println("All invitations written!");

        // NOTE: invitationNumber is NOT accessible here.
        // Variables declared in the initializer are scoped to the loop only.
        // This is intentional — it prevents counter variables from leaking
        // into surrounding code where they have no meaning.
    }
}

Looping Through an Array — The Most Common Real-World Use Case

The single most common use of a for loop in Java is walking through every element of an array. An array is a numbered list of values where every slot has an index. The critical detail — the one that causes more beginner crashes than anything else — is that Java arrays are zero-indexed. The first element lives at index 0, not index 1.

A 5-element array has indices 0, 1, 2, 3, and 4. The last valid index is always array.length - 1. There is no index 5 in a 5-element array. Ask for it and Java throws ArrayIndexOutOfBoundsException immediately at runtime with no warning beforehand.

This is precisely why the standard idiom for looping through an array is i < array.length with a strict less-than, not i <= array.length. With <=, when the counter reaches array.length (which is 5 for a 5-element array), the condition is still true, Java tries to read array[5], finds nothing there, and crashes.

The loop counter doubling as the array index is the elegant core of this pattern. You are not maintaining two separate things — the position in the array and the current iteration number are the same value. That is by design.

One practical note: if you only need the values and do not need the index for anything, the enhanced for-each loop (for (int score : testScores)) is cleaner. But the moment you need the position — to compare adjacent elements, to write back to the array, to display 'Score 3 of 5' — you need the indexed for loop.

public class StudentScoreCalculator {
    public static void main(String[] args) {

        // Five test scores stored in an array.
        // Index positions:  [0]=85  [1]=92  [2]=78  [3]=95  [4]=88
        // array.length = 5, but valid indices are 0 through 4.
        int[] testScores = {85, 92, 78, 95, 88};

        int totalScore = 0;

        // i < testScores.length means i runs from 0 to 4 — exactly the valid indices.
        // The moment i reaches 5, the condition is false and the loop exits cleanly.
        //
        // If we wrote i <= testScores.length:
        //   When i = 5, condition is true (5 <= 5), Java tries testScores[5].
        //   testScores[5] does not exist. JVM throws ArrayIndexOutOfBoundsException.
        //   Program crashes with no output for that iteration.
        for (int i = 0; i < testScores.length; i++) {

            // i is the array index. (i + 1) is the human-readable position.
            // We use i for access, (i + 1) for display. Do not start i at 1.
            System.out.println("Score " + (i + 1) + ": " + testScores[i]);

            // Accumulate the running total.
            totalScore = totalScore + testScores[i];
        }

        // Cast to double before dividing to get a decimal result.
        // Without the cast, integer division truncates: 438 / 5 = 87, not 87.6.
        double averageScore = (double) totalScore / testScores.length;

        System.out.println("----------------------------");
        System.out.println("Total Score  : " + totalScore);
        System.out.printf("Average Score: %.1f%n", averageScore);
    }
}

Nested for Loops — Loops Inside Loops (And When You Actually Need Them)

Sometimes one dimension of repetition is not enough. Printing a multiplication table requires every number from 1 to 10 multiplied by every other number from 1 to 10. Processing a 2D grid of pixels requires visiting every row and every column. Comparing every element in a list against every other element requires two passes through the data. These are inherently two-dimensional problems, and nested loops are how Java handles two dimensions.

A nested loop is a loop inside another loop. The outer loop controls one dimension — typically rows. The inner loop controls the other — typically columns. For every single iteration of the outer loop, the inner loop runs its full cycle from start to finish. If the outer loop runs 5 times and the inner loop runs 5 times, the body executes 25 times.

That multiplication is the key insight and the key danger. Two loops with bounds of 1000 each produce one million iterations. At one microsecond per iteration — a reasonable estimate for simple arithmetic — that is one second. Add a database call inside the inner loop at 10ms each and you are at 2.7 hours. Nested loops with large bounds and non-trivial inner bodies are a reliable path to production timeouts.

Before writing a nested loop, always calculate the total iterations explicitly. If N × M is larger than your data set comfortably allows within your latency budget, you need a different algorithm — often a HashMap or Set that turns an O(N²) comparison into O(N).

Variable naming in nested loops is not a style preference — it is a correctness requirement. Using i for both loops means the inner loop's i shadows the outer loop's i. The outer counter stops updating correctly and the output is wrong in a way that is genuinely confusing to debug. Use i and j, or better, use descriptive names like row and col that make the two-dimensional intent clear.

public class MultiplicationTable {
    public static void main(String[] args) {

        int tableSize = 5; // 5x5 table — 25 total cell calculations

        System.out.println("--- 5x5 Multiplication Table ---");

        // OUTER LOOP: controls which row we are on (1 through 5).
        // This loop runs 5 times total.
        for (int row = 1; row <= tableSize; row++) {

            // INNER LOOP: controls which column we are on (1 through 5).
            // For every single value of 'row', this inner loop runs
            // completely from col=1 to col=5 before 'row' increments.
            //
            // 'row' and 'col' are separate variables — critical.
            // Using 'i' for both would cause the inner loop to overwrite
            // the outer counter, breaking the outer loop silently.
            for (int col = 1; col <= tableSize; col++) {

                int product = row * col;

                // %4d: print an integer right-aligned in a 4-character-wide field.
                // Without this padding, columns would not align and the table
                // would be unreadable for two-digit products.
                System.out.printf("%4d", product);
            }

            // After the inner loop completes one full row of columns,
            // print a newline to start the next row.
            // This println is part of the OUTER loop body, not the inner.
            System.out.println();
        }

        // Total body executions: 5 rows x 5 columns = 25
        // For a 1000x1000 table that would be 1,000,000 executions.
        // Always think about N x M before nesting loops.
    }
}

Controlling Loop Flow with break and continue

Sometimes you need to exit a loop before it naturally finishes, or skip one specific iteration without stopping the whole loop. Java provides two keywords for exactly these situations: break and continue.

break is the emergency exit. The moment Java encounters break, it leaves the current loop entirely — no more iterations, no revisiting the condition, no cleanup. Execution continues with the first line after the loop's closing brace. This is the right tool when you are searching for something and have found it. Checking the remaining elements would be wasted work.

continue is more nuanced. It does not stop the loop — it abandons only the current iteration and jumps immediately to the update step, then rechecks the condition. The loop continues normally from the next iteration. Think of it as 'never mind this one, move on.' This is useful when most elements need processing but a specific subset should be skipped — blank entries, null values, filtered-out categories.

The failure mode when you confuse them is silent: your code runs without error but produces wrong results. break when you meant continue terminates the loop too early, silently skipping every remaining element. continue when you meant break keeps processing elements you should have stopped at, potentially corrupting state or producing extra output. Neither produces a compile error or exception. The bug hides in the output.

One important scoping rule: both keywords only affect the loop they are directly inside. In a nested loop, break in the inner loop exits the inner loop and returns control to the outer loop — the outer loop continues. To exit the outer loop from inside the inner loop, use a boolean flag checked in the outer loop's condition, or use a labeled break if your team accepts that style.

public class SecurityScanner {
    public static void main(String[] args) {

        // Simulating a username list going through a security scan.
        //
        // Rules:
        //   1. Skip blank usernames — nothing to check, move on (continue)
        //   2. Stop the entire scan if a banned user is found (break)
        //   3. Log every username that passes both checks
        String[] usernames = {"alice", "bob", "", "charlie", "BANNED_USER", "diana"};

        System.out.println("Starting security scan...");

        for (int i = 0; i < usernames.length; i++) {

            // Rule 1: blank username — skip this slot, continue to the next.
            // 'continue' jumps to i++ then rechecks i < usernames.length.
            // The code below this block does NOT run for this iteration.
            if (usernames[i].isEmpty()) {
                System.out.println("Slot " + i + ": empty — skipping.");
                continue; // jumps to update step (i++), not to end of loop
            }

            // Rule 2: banned user found — raise alert and stop scanning entirely.
            // 'break' exits the for loop completely.
            // "diana" at slot 5 will never be checked — this is intentional.
            if (usernames[i].equals("BANNED_USER")) {
                System.out.println("ALERT: Banned user detected at slot " + i + "! Halting scan.");
                break; // exits the for loop, goes to "Scan complete."
            }

            // This line only runs if NEITHER condition above triggered.
            // If continue fired, we never reach here for that iteration.
            // If break fired, we never reach here for any future iteration.
            System.out.println("Slot " + i + ": '" + usernames[i] + "' cleared.");
        }

        // This line runs regardless of whether the loop ended naturally
        // or was exited early via break. break exits the loop, not the method.
        System.out.println("Scan complete.");
    }
}

The Enhanced For-Each — When Your Loop Variable Is a Liability

You've been writing for (int i = 0; i < list.size(); i++) like it's 2004. Stop. Java's enhanced for-each loop eliminates index arithmetic, off-by-one errors, and the useless boilerplate of manually incrementing a counter.

The syntax is dead simple: for (ElementType variable : collection). The JVM handles the iteration mechanics. You don't touch the index. You don't call get(i). You just work with each element directly.

This isn't about syntactic sugar. It's about eliminating an entire class of bugs. Every time you write list.get(i), you're trusting that i stays within bounds. Every time you write i++, you're introducing a mutation that could be corrupted by a continue or a break. The for-each abstracts that risk away.

But here's the catch: you can't modify the underlying collection during iteration — you'll get a ConcurrentModificationException. And you can't access the index. For those cases, stick with the classic for loop. But for everything else, use for-each. Your code reviewer will thank you.

// io.thecodeforge — java tutorial

import java.util.List;

public class IterateOrders {
    public static void main(String[] args) {
        List<String> orders = List.of("ORD-1001", "ORD-1002", "ORD-1003");

        // Classic loop — error-prone
        for (int i = 0; i < orders.size(); i++) {
            System.out.println("Processing: " + orders.get(i));
        }

        // Enhanced for-each — clean and safe
        for (String orderId : orders) {
            System.out.println("Processing: " + orderId);
        }
    }
}

Labeled Loops — The Escape Hatch for Nested Chaos

Nested loops are a necessary evil. You iterate over customers, then over their orders, then over line items. Three levels deep. Then you find what you need and want to break out of all three loops at once.

A plain break only escapes the innermost loop. You'd end up with a boolean flag, an if check after every inner loop, and code that looks like a flowchart exploded. Labeled loops fix this.

Here's how it works: you slap a label before the outermost loop — search: for example — and then write break search; when you want to bail out entirely. Same goes for continue search;, which skips to the next iteration of the labeled loop.

Most developers don't know this exists. Some will argue it's 'goto in disguise'. They're wrong. It's a targeted, readable way to control flow in deeply nested structures. Use it sparingly — if you need more than one labeled loop in a method, refactor. But for that one case where you're three loops deep and the data matches, it's the cleanest hammer in the toolbox.

// io.thecodeforge — java tutorial

public class FindTargetOrder {
    public static void main(String[] args) {
        String[][] inventory = {
            {"SKU-001", "SKU-002"},
            {"SKU-003", "SKU-TARGET", "SKU-004"},
            {"SKU-005"}
        };

        String targetSku = "SKU-TARGET";

        search:
        for (int row = 0; row < inventory.length; row++) {
            for (int col = 0; col < inventory[row].length; col++) {
                if (inventory[row][col].equals(targetSku)) {
                    System.out.println("Found at row " + row + ", col " + col);
                    break search;  // exits both loops
                }
            }
        }

        System.out.println("Search complete.");
    }
}

The Infinite Loop — When It's a Bug vs. When It's a Feature

The classic for (;;) is the compressed version of an infinite loop. Every developer writes one accidentally at least once — usually because they forgot the update statement. But infinite loops aren't always bugs. They're a deliberate pattern for daemon threads, event listeners, and connection pools that need to run until the application shuts down.

When you write a deliberate infinite loop, you MUST include an explicit exit condition. A break on a flag, a caught interrupt, or a timeout. Otherwise, your loop is a resource leak waiting to happen. The JVM won't save you — it will happily burn CPU cycles until you kill the process.

The three parts of the for loop are all optional. Omit them all, and you get for (;;). Omit just the condition, and it's still infinite — the JVM treats an empty condition as true. Same effect, slightly less obvious. Be explicit with while (true) if you want clarity, but for (;;) is idiomatic and just as readable to anyone who's been doing this more than a year.

Real-world usage: a message listener polling a queue. Start it in a thread, loop forever, process messages, and exit only when someone sets a volatile running flag to false. Your shutdown hook sets the flag, the loop breaks, the thread joins gracefully. No System.exit(), no hanging threads, no cleanup failures.

// io.thecodeforge — java tutorial

public class DeliberateInfiniteLoop {
    private static volatile boolean running = true;

    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            int counter = 0;
            for (;;) {
                if (!running) {
                    System.out.println("Shutdown signal received. Exiting.");
                    break;
                }
                System.out.println("Processing message #" + counter++);
                try {
                    Thread.sleep(500);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                    break;
                }
            }
        });

        worker.start();
        Thread.sleep(2000);
        running = false;
        worker.join();
        System.out.println("Worker terminated cleanly.");
    }
}

Traversing an Array? Your Loop Order Controls Performance

Arrays in Java are laid out sequentially in memory. That’s not trivia — that’s your cache coherency bonus. When you traverse from index 0 to length-1, you hit sequential memory addresses. The CPU prefetches the next few cache lines automatically. Your loop runs at memory speed, not CPU speed.

Reverse traversal? Same benefit — the hardware doesn’t care about direction. What kills you is striding: jumping by 2, 5, or accessing columns in a 2D array row-by-row but reading column-by-column. That skips cache lines and forces DRAM fetches. Your loop goes from nanoseconds to hundreds of nanoseconds per access.

If you’re processing an int[1000000], simple forward iteration is optimal. Don’t overthink it. The JVM’s JIT compiler also unrolls small fixed-size arrays. Write clear sequential loops. Let the hardware and JIT do the rest.

// io.thecodeforge — java tutorial

public class ArrayTraverse {
    public static void main(String[] args) {
        int[] prices = { 349, 499, 599, 799, 1099 };
        int total = 0;

        for (int i = 0; i < prices.length; i++) {
            total += prices[i];
        }

        System.out.println("Total: " + total);
    }
}

Collections Are Not Arrays — For-Each Hides the Iterator, Not the Cost

When you write for (String s : list) on an ArrayList, you get a linear pass. Fast. Same loop on a LinkedList? Your code looks identical, but your performance is abysmal. The for-each uses the collection’s iterator. ArrayList’s iterator jumps by index — O(1) per step. LinkedList’s iterator walks a node chain — O(1) per step, but the cache misses hurt. More importantly, you cannot modify the collection inside a for-each without a ConcurrentModificationException.

If you need to remove items mid-loop, use an explicit Iterator with Iterator.remove(). If you need index-based access on a List, use a traditional for loop with get(). That’s O(1) on ArrayList but O(n) on LinkedList — so pick your data structure first.

For HashMap, never iterate over entrySet() and call get(key) inside the loop. You’re doing double work. Use for (Map.Entry<K,V> entry : map.entrySet()) — one pass, one lookup.

// io.thecodeforge — java tutorial

import java.util.*;

public class CollectionLoop {
    public static void main(String[] args) {
        List<String> messages = new ArrayList<>();
        messages.add("alpha");
        messages.add("beta");
        messages.add("gamma");

        for (String msg : messages) {
            System.out.println(msg + "!");
        }
    }
}

Iterable.forEach() — The Internal Iterator That Breaks Your Control

Java 8 added a default method to Iterable: forEach(). It takes a Consumer lambda and iterates internally. The WHY: you trade loop control for cleaner code when you only need to apply an operation to each element. Unlike a for-each loop, forEach() cannot use break, continue, or return to exit early — the lambda runs to completion on every element. This becomes a production trap when you assume you can short-circuit; the compiler won't stop you, but your logic will silently process the entire collection. Use forEach() when you must unconditionally process every element and want a purely functional style. For conditional iteration, stick with the explicit for loop.

// io.thecodeforge — java tutorial

import java.util.List;

public class ForEachBreakBug {
    public static void main(String[] args) {
        List<Integer> numbers = List.of(1, 2, 3, 4, 5);
        
        // This DOES NOT break — it compiles, but processes all 5 elements.
        numbers.forEach(n -> {
            if (n > 3) return;  // returns from lambda, NOT the loop
            System.out.print(n + " ");
        });
        // Output: 1 2 3  (no early exit — just skips printing for 4,5)
        System.out.println();
    }
}

The Hidden Cost of forEach on Parallel Streams — Not All Iteration Is Sequential

Collection.forEach() always runs sequentially on the calling thread. But the default method is inherited by streams, and Stream.forEach() does NOT guarantee encounter order when run on a parallel stream. The WHY: parallel processing splits the stream into substreams; forEach processes results as they arrive, not in original order. If you need ordered processing under parallelism, use forEachOrdered(). A common performance pitfall: developers call parallelStream().forEach() expecting order, then add synchronization to fix nondeterministic output — which kills parallel speed. For ordered parallel iteration, prefer forEachOrdered() or stick to sequential for-each. For unordered operations, forEach() on parallel streams gives maximum throughput.

// io.thecodeforge — java tutorial

import java.util.List;

public class ParallelForEachOrder {
    public static void main(String[] args) {
        List<Integer> ids = List.of(1, 2, 3, 4, 5);
        
        System.out.print("parallelStream().forEach(): ");
        ids.parallelStream().forEach(i -> System.out.print(i + " "));
        // Output: order is unpredictable (e.g., 3,1,4,2,5)
        
        System.out.print("\nparallelStream().forEachOrdered(): ");
        ids.parallelStream().forEachOrdered(i -> System.out.print(i + " "));
        // Output: 1 2 3 4 5 (ordered but slower)
    }
}