我认为你应该使用这样的东西，它被称为Upcasting:

public int multiplyBy2(int x) throws ArithmeticException {
    long result = 2 * (long) x;    
    if (result > Integer.MAX_VALUE || result < Integer.MIN_VALUE){
        throw new ArithmeticException("Integer overflow");
    }
    return (int) result;
}

你可以在这里进一步阅读: 检测或防止整数溢出

这是相当可靠的来源。

它环绕着。

e.g:

public class Test {

    public static void main(String[] args) {
        int i = Integer.MAX_VALUE;
        int j = Integer.MIN_VALUE;

        System.out.println(i+1);
        System.out.println(j-1);
    }
}

打印

-2147483648
2147483647

从java8开始，java.lang.Math包就有了addExact()和multiplyExact()这样的方法，它们会在发生溢出时抛出一个ArithmeticException。

我认为你应该使用这样的东西，它被称为Upcasting:

public int multiplyBy2(int x) throws ArithmeticException {
    long result = 2 * (long) x;    
    if (result > Integer.MAX_VALUE || result < Integer.MIN_VALUE){
        throw new ArithmeticException("Integer overflow");
    }
    return (int) result;
}

你可以在这里进一步阅读: 检测或防止整数溢出

这是相当可靠的来源。

有一些库提供安全的算术操作，用于检查整数溢出/下溢。例如，Guava的IntMath。checkedAdd(int a, int b)返回a和b的和，前提是它没有溢出，如果a + b在有符号int算术中溢出，则抛出arithmeexception。

Java对int或长基元类型的整数溢出没有做任何处理，而是忽略正整数和负整数溢出。

这个答案首先描述了整数溢出的原因，给出了一个例子，说明了它是如何发生的，即使是表达式求值中的中间值，然后给出了一些资源的链接，这些资源提供了防止和检测整数溢出的详细技术。

整数算术和表达式导致意外或未检测到的溢出是常见的编程错误。意外或未检测到的整数溢出也是一个众所周知的可利用的安全问题，特别是当它影响数组、堆栈和列表对象时。

溢出可能以正或负的方向发生，其中正或负的值将超过所讨论的基元类型的最大值或最小值。在表达式或操作求值期间，中间值可能发生溢出，并影响最终值在范围内的表达式或操作的结果。

Sometimes negative overflow is mistakenly called underflow. Underflow is what happens when a value would be closer to zero than the representation allows. Underflow occurs in integer arithmetic and is expected. Integer underflow happens when an integer evaluation would be between -1 and 0 or 0 and 1. What would be a fractional result truncates to 0. This is normal and expected with integer arithmetic and not considered an error. However, it can lead to code throwing an exception. One example is an "ArithmeticException: / by zero" exception if the result of integer underflow is used as a divisor in an expression.

考虑下面的代码:

int bigValue = Integer.MAX_VALUE;
int x = bigValue * 2 / 5;
int y = bigValue / x;

这将导致x被赋值为0，并且bigValue / x的后续求值会抛出一个异常，“ArithmeticException: / by zero”(即除以0)，而不是将y赋值为2。

x的预期结果是858,993,458，小于最大int值2,147,483,647。但是，计算Integer的中间结果。MAX_Value * 2，将是4,294,967,294，它超过了最大int值，并根据2s补全整数表示为-2。然后-2 / 5的结果是0，赋值给x。

将计算x的表达式重新排列为在求值时先除后乘的表达式，如下代码:

int bigValue = Integer.MAX_VALUE;
int x = bigValue / 5 * 2;
int y = bigValue / x;

结果x被赋值为858,993,458,y被赋值为2，这是预期的。

bigValue / 5的中间结果是429,496,729，它没有超过int类型的最大值。随后计算429,496,729 * 2不会超过int的最大值，预期结果被分配给x。然后对y的计算不除零。对x和y的求值按预期工作。

Java integer values are stored as and behave in accordance with 2s complement signed integer representations. When a resulting value would be larger or smaller than the maximum or minimum integer values, a 2's complement integer value results instead. In situations not expressly designed to use 2s complement behavior, which is most ordinary integer arithmetic situations, the resulting 2s complement value will cause a programming logic or computation error as was shown in the example above. An excellent Wikipedia article describes 2s compliment binary integers here: Two's complement - Wikipedia

有一些技术可以避免意外的整数溢出。技术可以分为使用前置条件测试、向上转换和BigInteger。

前置条件测试包括检查进入算术运算或表达式的值，以确保这些值不会发生溢出。编程和设计将需要创建测试，以确保输入值不会导致溢出，然后确定如果发生导致溢出的输入值该怎么办。

Upcasting comprises using a larger primitive type to perform the arithmetic operation or expression and then determining if the resulting value is beyond the maximum or minimum values for an integer. Even with upcasting, it is still possible that the value or some intermediate value in an operation or expression will be beyond the maximum or minimum values for the upcast type and cause overflow, which will also not be detected and will cause unexpected and undesired results. Through analysis or pre-conditions, it may be possible to prevent overflow with upcasting when prevention without upcasting is not possible or practical. If the integers in question are already long primitive types, then upcasting is not possible with primitive types in Java.

The BigInteger technique comprises using BigInteger for the arithmetic operation or expression using library methods that use BigInteger. BigInteger does not overflow. It will use all available memory, if necessary. Its arithmetic methods are normally only slightly less efficient than integer operations. It is still possible that a result using BigInteger may be beyond the maximum or minimum values for an integer, however, overflow will not occur in the arithmetic leading to the result. Programming and design will still need to determine what to do if a BigInteger result is beyond the maximum or minimum values for the desired primitive result type, e.g., int or long.

卡内基梅隆软件工程研究所的CERT程序和Oracle已经为安全Java编程创建了一套标准。这些标准包括防止和检测整数溢出的技术。该标准作为一个免费的在线资源发布:CERT Oracle Java安全编码标准

该标准的部分描述并包含了防止或检测整数溢出的编码技术的实际示例:NUM00-J。检测或防止整数溢出

图书形式和PDF形式的CERT Oracle Java安全编码标准也可用。

好吧，就基本整数类型而言，Java根本不处理Over/Underflow(对于float和double的行为是不同的，它将刷新到+/-无穷大，就像IEEE-754要求的那样)。

当添加两个int时，当发生溢出时将不会得到任何指示。检查溢出的一个简单方法是使用下一个更大的类型来实际执行操作，并检查结果是否仍然在源类型的范围内:

public int addWithOverflowCheck(int a, int b) {
    // the cast of a is required, to make the + work with long precision,
    // if we just added (a + b) the addition would use int precision and
    // the result would be cast to long afterwards!
    long result = ((long) a) + b;
    if (result > Integer.MAX_VALUE) {
         throw new RuntimeException("Overflow occured");
    } else if (result < Integer.MIN_VALUE) {
         throw new RuntimeException("Underflow occured");
    }
    // at this point we can safely cast back to int, we checked before
    // that the value will be withing int's limits
    return (int) result;
}

你会做什么来代替throw子句，这取决于你的应用程序的需求(throw，刷新到最小/最大或只是记录)。如果您想检测长操作上的溢出，则无法使用原语，请使用BigInteger代替。

编辑(2014-05-21):由于这个问题似乎经常被提及，我不得不自己解决同样的问题，用CPU计算V标志位的相同方法来评估溢出状况是很容易的。

它基本上是一个布尔表达式，包含两个操作数的符号以及结果:

/**
 * Add two int's with overflow detection (r = s + d)
 */
public static int add(final int s, final int d) throws ArithmeticException {
    int r = s + d;
    if (((s & d & ~r) | (~s & ~d & r)) < 0)
        throw new ArithmeticException("int overflow add(" + s + ", " + d + ")");    
    return r;
}

在java中，将表达式(在if中)应用到整个32位更简单，并使用< 0检查结果(这将有效地测试符号位)。该原理对所有整数基元类型都是完全相同的，将上述方法中的所有声明都更改为long可以使其工作为long。

对于较小的类型，由于隐式转换为int(详细信息请参阅JLS逐位操作)，检查不检查< 0，检查需要显式屏蔽符号位(短操作数为0x8000，字节操作数为0x80，适当调整类型转换和参数声明):

/**
 * Subtract two short's with overflow detection (r = d - s)
 */
public static short sub(final short d, final short s) throws ArithmeticException {
    int r = d - s;
    if ((((~s & d & ~r) | (s & ~d & r)) & 0x8000) != 0)
        throw new ArithmeticException("short overflow sub(" + s + ", " + d + ")");
    return (short) r;
}

(注意，上面的例子使用了表达式需要进行减法溢出检测)

那么这些布尔表达式是如何/为什么工作的呢?首先，一些逻辑思维表明，只有当两个参数的符号相同时才会发生溢出。因为，如果一个参数为负，一个参数为正，add的结果必须接近于零，或者在极端情况下，一个参数为零，与另一个参数相同。由于参数本身不能创建溢出条件，它们的和也不能创建溢出。

So what happens if both arguments have the same sign? Lets take a look at the case both are positive: adding two arguments that create a sum larger than the types MAX_VALUE, will always yield a negative value, so an overflow occurs if arg1 + arg2 > MAX_VALUE. Now the maximum value that could result would be MAX_VALUE + MAX_VALUE (the extreme case both arguments are MAX_VALUE). For a byte (example) that would mean 127 + 127 = 254. Looking at the bit representations of all values that can result from adding two positive values, one finds that those that overflow (128 to 254) all have bit 7 set, while all that do not overflow (0 to 127) have bit 7 (topmost, sign) cleared. Thats exactly what the first (right) part of the expression checks:

if (((s & d & ~r) | (~s & ~d & r)) < 0)

(~s & ~d & r)为真，仅当两个操作数(s, d)为正且结果(r)为负时才为真(该表达式适用于所有32位，但我们唯一感兴趣的位是最上面的(符号)位，它由< 0检查)。

Now if both arguments are negative, their sum can never be closer to zero than any of the arguments, the sum must be closer to minus infinity. The most extreme value we can produce is MIN_VALUE + MIN_VALUE, which (again for byte example) shows that for any in range value (-1 to -128) the sign bit is set, while any possible overflowing value (-129 to -256) has the sign bit cleared. So the sign of the result again reveals the overflow condition. Thats what the left half (s & d & ~r) checks for the case where both arguments (s, d) are negative and a result that is positive. The logic is largely equivalent to the positive case; all bit patterns that can result from adding two negative values will have the sign bit cleared if and only if an underflow occured.