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

至于实用的建议:

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

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

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

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

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

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

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

因为无符号类型是纯粹的邪恶。

事实上，在C语言中unsigned int生成unsigned更是邪恶的。

下面是一个让我不止一次头疼的问题的快照:

// We have odd positive number of rays, 
// consecutive ones at angle delta from each other.
assert( rays.size() > 0 && rays.size() % 2 == 1 );

// Get a set of ray at delta angle between them.
for( size_t n = 0; n < rays.size(); ++n )
{
    // Compute the angle between nth ray and the middle one.
    // The index of the middle one is (rays.size() - 1) / 2,
    // the rays are evenly spaced at angle delta, therefore
    // the magnitude of the angle between nth ray and the 
    // middle one is: 
    double angle = delta * fabs( n - (rays.size() - 1) / 2 ); 

    // Do something else ...
}

你注意到这个bug了吗?我承认我是在使用调试器之后才看到它的。

由于n是无符号类型size_t，整个表达式n - (ray .size() - 1) / 2的计算结果为无符号。该表达式旨在表示从中间那条线开始的第n条射线的符号位置:从左边那条线开始的第1条射线的位置为-1，右边那条线的位置为+1，等等。在取abs值并乘以角之后，我将得到第n条射线与中间那条射线之间的夹角。

不幸的是，对我来说，上面的表达式包含了邪恶的unsigned，它的计算结果不是-1，而是2^32-1。随后转换为双密封的bug。

由于滥用无符号算术而导致的一两个错误之后，人们不得不开始考虑获得的额外比特是否值得额外的麻烦。我正在尽可能地避免在算术中使用无符号类型，尽管仍然将它用于非算术操作，如二进制掩码。

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

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

在“C”规范中，有一些因实用主义原因而被Java抛弃的珍宝，但随着开发人员的需求(闭包等)，它们正在慢慢地回归。

我提到第一个是因为它和这个讨论有关;指针值对无符号整数算术的坚持。并且，与这个主题相关的是，在Java的Signed世界中维护Unsigned语义的困难。

我猜如果有人让Dennis Ritchie的另一个自我来建议Gosling的设计团队，他会建议给Signed's一个“无穷大的零”，这样所有的地址偏移请求都会先加上他们的algeaic RING SIZE来消除负值。

这样，向数组抛出的任何偏移量都不会生成SEGFAULT。例如，在一个封装类中，我称之为RingArray的双精度对象需要unsigned行为-在“自旋转循环”上下文中:

// ...
// Housekeeping state variable
long entrycount;     // A sequence number
int cycle;           // Number of loops cycled
int size;            // Active size of the array because size<modulus during cycle 0
int modulus;         // Maximal size of the array

// Ring state variables
private int head;   // The 'head' of the Ring
private int tail;   // The ring iterator 'cursor'
// tail may get the current cursor position
// and head gets the old tail value
// there are other semantic variations possible

// The Array state variable
double [] darray;    // The array of doubles

// somewhere in constructor
public RingArray(int modulus) {
    super();
    this.modulus = modulus;
    tail =  head =  cycle = 0;
    darray = new double[modulus];
// ...
}
// ...
double getElementAt(int offset){
    return darray[(tail+modulus+offset%modulus)%modulus];
}
//  remember, the above is treating steady-state where size==modulus
// ...

上面的RingArray永远不会从负索引中“获得”，即使恶意请求者试图这样做。记住，还有许多合法的请求用于请求先前的(负的)索引值。

注意:外层%模数去掉了对合法请求的引用，而内部%模数掩盖了明显的恶意，因为负数比-模数更负。如果这将出现在Java +..9 || 8+…+ spec，那么问题将真正成为一个“程序员不能“自我旋转”的错误”。

我相信所谓的Java unsigned int“缺陷”可以用上面的一行程序来弥补。

PS:只是为了给上面的RingArray管理提供上下文，这里有一个候选的'set'操作来匹配上面的'get'元素操作:

void addElement(long entrycount,double value){ // to be called only by the keeper of entrycount
    this.entrycount= entrycount;
    cycle = (int)entrycount/modulus;
    if(cycle==0){                       // start-up is when the ring is being populated the first time around
        size = (int)entrycount;         // during start-up, size is less than modulus so use modulo size arithmetic
        tail = (int)entrycount%size;    //  during start-up
    }
    else {
        size = modulus;
        head = tail;
        tail = (int)entrycount%modulus; //  after start-up
    }
    darray[head] = value;               //  always overwrite old tail
}

一旦有符号整型和无符号整型混合在表达式中，事情就开始变得混乱，你可能会丢失信息。将Java限制为有符号int型只能真正解决问题。我很高兴我不必担心整个有符号/无符号的问题，尽管我有时会错过字节中的第8位。