Introduction

Computing the average of three long values sounds trivial until the numbers are large enough for overflow to matter. The dangerous part is not the division by three; it is the intermediate sum, because adding three valid long values can exceed the range of the type even when the final average would fit comfortably.

The Naive Formula Can Overflow

This version looks correct but is not always safe:

long average = (a + b + c) / 3;

If a, b, and c are near Long.MAX_VALUE, the addition happens before the division and may overflow. Java long arithmetic wraps around silently, so the result can become a completely wrong negative or otherwise corrupted value.

1long a = Long.MAX_VALUE;
2long b = Long.MAX_VALUE;
3long c = Long.MAX_VALUE;
4
5long average = (a + b + c) / 3;
6System.out.println(average);

That prints the wrong answer because the sum overflowed before division.

A Safe Integer Average Without Overflow

For an integer result that truncates toward zero, divide first and handle the remainders separately.

long average = a / 3 + b / 3 + c / 3
        + (a % 3 + b % 3 + c % 3) / 3;

Why this works:

• each division step reduces the magnitude before addition
• each remainder is small, so their sum stays within a tiny range
• the final result matches normal integer division semantics

Here is a complete example:

1public class SafeAverage {
2    public static long averageOfThree(long a, long b, long c) {
3        return a / 3 + b / 3 + c / 3
4                + (a % 3 + b % 3 + c % 3) / 3;
5    }
6
7    public static void main(String[] args) {
8        long a = Long.MAX_VALUE;
9        long b = Long.MAX_VALUE;
10        long c = Long.MAX_VALUE;
11
12        System.out.println(averageOfThree(a, b, c));
13    }
14}

For integer output, this is a good general-purpose technique.

If You Need a Fractional Average

Sometimes you want the mathematically exact average as a decimal, not truncated integer division. In that case, convert before summing or use arbitrary-precision arithmetic.

Using double is simple:

double average = ((double) a + (double) b + (double) c) / 3.0;

This avoids long overflow because the addition happens in floating-point. It is usually fine for reporting or analytics, but it may lose integer precision for very large values because double cannot represent every 64-bit integer exactly.

If exactness matters, use BigInteger or BigDecimal.

1import java.math.BigDecimal;
2import java.math.BigInteger;
3
4BigInteger sum = BigInteger.valueOf(a)
5        .add(BigInteger.valueOf(b))
6        .add(BigInteger.valueOf(c));
7
8BigDecimal average = new BigDecimal(sum).divide(BigDecimal.valueOf(3));
9System.out.println(average);

That version is slower but exact.

Picking the Right Method

If the requirement is "return a long average with normal integer truncation," use the division-and-remainder technique. If the requirement is "show a decimal average," decide whether floating-point precision is acceptable. If not, move to BigDecimal.

The right answer depends less on syntax and more on the contract of your function. Many bugs happen because developers compute a floating-point average when the caller expected integer semantics, or vice versa.

Common Pitfalls

The first pitfall is assuming overflow only matters when the final answer is large. That is false. Intermediate arithmetic can overflow even when the final average is small enough to fit.

Another issue is forgetting that integer division truncates. For example, averaging 1, 2, and 2 with integer arithmetic gives 1, not 1.666.... That may be correct or incorrect depending on the requirement.

Developers also mix signed values without testing negative cases. The safe integer formula still works, but if your code relies on a specific rounding policy beyond Java's normal truncation toward zero, you need to define and test that policy explicitly.

Finally, avoid converting to double blindly in financial or audit-sensitive code. Floating-point is convenient, but exact decimal behavior often matters more than speed.

Summary

• '(a + b + c) / 3 is unsafe for large long values because the sum can overflow first.'
• For an integer result, divide each term first and combine the remainders safely.
• For a fractional result, casting to double is convenient but not always exact.
• Use BigInteger or BigDecimal when precision matters more than performance.
• Always decide whether your API promises truncation, rounding, or exact decimal output.