http://skeletoncoder.blogspot.com/2006/09/java-tutorials-why-no-unsigned.html

这个家伙说，因为C标准定义了包含无符号整型和有符号整型的操作被视为无符号整型。这可能导致负符号整数滚动到一个大的无符号整数，可能会导致错误。

在JDK8中，它确实提供了一些支持。

尽管有Gosling的担忧，但我们仍然可能看到Java对unsigned类型的完全支持。

I once took a C++ course with someone on the C++ standards committee who implied that Java made the right decision to avoid having unsigned integers because (1) most programs that use unsigned integers can do just as well with signed integers and this is more natural in terms of how people think, and (2) using unsigned integers results in lots easy to create but difficult to debug issues such as integer arithmetic overflow and losing significant bits when converting between signed and unsigned types. If you mistakenly subtract 1 from 0 using signed integers it often more quickly causes your program to crash and makes it easier to find the bug than if it wraps around to 2^32 - 1, and compilers and static analysis tools and runtime checks have to assume you know what you're doing since you chose to use unsigned arithmetic. Also, negative numbers like -1 can often represent something useful, like a field being ignored/defaulted/unset while if you were using unsigned you'd have to reserve a special value like 2^32 - 1 or something similar.

Long ago, when memory was limited and processors did not automatically operate on 64 bits at once, every bit counted a lot more, so having signed vs unsigned bytes or shorts actually mattered a lot more often and was obviously the right design decision. Today just using a signed int is more than sufficient in almost all regular programming cases, and if your program really needs to use values bigger than 2^31 - 1, you often just want a long anyway. Once you're into the territory of using longs, it's even harder to come up with a reason why you really can't get by with 2^63 - 1 positive integers. Whenever we go to 128 bit processors it'll be even less of an issue.

我认为Java本身就很好，添加unsigned会使它变得复杂而没有太多好处。 即使使用简化的整数模型，大多数Java程序员也不知道基本的数字类型是如何行为的——只要阅读《Java Puzzlers》一书，就能了解您可能持有的误解。

至于实用的建议:

如果你的值是任意大小，不适合int，使用long。 如果它们不适合长期使用BigInteger。 只有在需要节省空间时，才对数组使用较小的类型。 如果你正好需要64/32/16/8位，使用long/int/short/byte，不要担心符号位，除法、比较、右移和强制转换除外。

另请参阅关于“将一个随机数生成器从C移植到Java”的回答。

Java确实有unsigned类型，或者至少有一个:char是一个unsigned short类型。所以不管高斯林找什么借口，他都不知道为什么没有其他无符号类型。

还有短型:短型一直被用于多媒体。原因是您可以在一个32位无符号长函数中拟合2个样本，并向量化许多操作。8位数据和无符号字节也是如此。你可以在一个寄存器中放入4或8个样本进行向量化。

字里行间，我认为逻辑是这样的:

通常，Java设计人员希望简化可用的数据类型 对于日常用途，他们认为最常见的需求是有符号的数据类型 为了实现某些算法，有时需要无符号算术，但是要实现这种算法的程序员也应该具备使用有符号数据类型进行无符号算术的知识

总的来说，我认为这是一个合理的决定。我可能会:

使字节无符号，或者至少为这一数据类型提供了有符号/无符号的替代选项，可能使用不同的名称(使它有符号有利于一致性，但什么时候需要有符号字节?) 不再使用“short”(你上次使用16位符号算术是什么时候?)

不过，只要稍加修饰，对32位以内的无符号值进行运算就不会太糟糕，而且大多数人不需要无符号64位除法或比较。