如果有人想要一个简单易用的版本，我在https://github.com/lfac-pt/Java-Pair上提供了我的版本。此外，非常欢迎改进!

@Andreas Krey的回答其实很好。任何Java给你带来困难的事情，你都不应该去做。

在我的经验中，Pair最常见的用途是一个方法的多个返回值和hashmap中的values(通常由字符串索引)。

在后一种情况下，我最近使用了一个数据结构，类似这样:

class SumHolder{MyObject trackedObject, double sum};

这是您的整个“Pair”类，与通用的“Pair”类的代码数量几乎相同，但具有描述性名称的优势。它可以在它使用的方法中定义，这将消除公共变量等典型问题。换句话说，对于这种用法，它绝对比一对更好(由于命名的成员)，不会更差。

If you actually want a "Pair" for the key of a hashmap you are essentially creating a double-key index. I think this may be the one case where a "Pair" is significantly less code. It's not really easier because you could have eclipse generate equals/hash on your little data class, but it would be a good deal more code. Here a Pair would be a quick fix, but if you need a double-indexed hash who's to say you don't need an n-indexed hash? The data class solution will scale up, the Pair will not unless you nest them!

So the second case, returning from a method, is a bit harder. Your class needs more visibility (the caller needs to see it too). You can define it outside the method but inside the class exactly as above. At that point your method should be able to return a MyClass.SumHolder object. The caller gets to see the names of the returned objects, not just a "Pair". Note again that the "Default" security of package level is pretty good--it's restrictive enough that you shouldn't get yourself into too much trouble. Better than a "Pair" object anyway.

我能看到的另一种情况是使用一个公共api，为当前包之外的调用者提供返回值。为此，我只创建一个真正的对象——最好是不可变的。最终，调用者将共享此返回值，并且使其可变可能会出现问题。这是Pair对象更糟糕的另一种情况——大多数Pair不能被设置为不可变的。

所有这些情况的另一个优点是——java类扩展，我的sum类需要第二个sum和“Created”标记，当我完成时，我将不得不扔掉Pair并使用其他东西，但如果Pair有意义，我的4个值的类至少仍然有意义。

在我看来，Java中没有Pair，因为如果你想直接在Pair上添加额外的功能(例如Comparable)，你必须绑定类型。在c++中，我们不在乎，如果组成一个pair的类型没有操作符<，则pair::operator <也不会被编译。

Comparable的一个例子:

public class Pair<F, S> implements Comparable<Pair<? extends F, ? extends S>> {
    public final F first;
    public final S second;
    /* ... */
    public int compareTo(Pair<? extends F, ? extends S> that) {
        int cf = compare(first, that.first);
        return cf == 0 ? compare(second, that.second) : cf;
    }
    //Why null is decided to be less than everything?
    private static int compare(Object l, Object r) {
        if (l == null) {
            return r == null ? 0 : -1;
        } else {
            return r == null ? 1 : ((Comparable) (l)).compareTo(r);
        }
    }
}

/* ... */

Pair<Thread, HashMap<String, Integer>> a = /* ... */;
Pair<Thread, HashMap<String, Integer>> b = /* ... */;
//Runtime error here instead of compile error!
System.out.println(a.compareTo(b));

Comparable与编译时检查类型参数是否可比较的示例:

public class Pair<
        F extends Comparable<? super F>, 
        S extends Comparable<? super S>
> implements Comparable<Pair<? extends F, ? extends S>> {
    public final F first;
    public final S second;
    /* ... */
    public int compareTo(Pair<? extends F, ? extends S> that) {
        int cf = compare(first, that.first);
        return cf == 0 ? compare(second, that.second) : cf;
    }
    //Why null is decided to be less than everything?
    private static <
            T extends Comparable<? super T>
    > int compare(T l, T r) {
        if (l == null) {
            return r == null ? 0 : -1;
        } else {
            return r == null ? 1 : l.compareTo(r);
        }
    }
}

/* ... */

//Will not compile because Thread is not Comparable<? super Thread>
Pair<Thread, HashMap<String, Integer>> a = /* ... */;
Pair<Thread, HashMap<String, Integer>> b = /* ... */;
System.out.println(a.compareTo(b));

这很好，但是这次您不能在Pair中使用不可比较的类型作为类型参数。 你可能会在一些实用程序类中使用很多comparator for Pair，但是c++的人可能不会理解。另一种方法是在类型层次结构中编写很多类，在类型参数上有不同的边界，但是有太多可能的边界和它们的组合……

public class Pair<K, V> {

    private final K element0;
    private final V element1;

    public static <K, V> Pair<K, V> createPair(K key, V value) {
        return new Pair<K, V>(key, value);
    }

    public Pair(K element0, V element1) {
        this.element0 = element0;
        this.element1 = element1;
    }

    public K getElement0() {
        return element0;
    }

    public V getElement1() {
        return element1;
    }

}

用法:

Pair<Integer, String> pair = Pair.createPair(1, "test");
pair.getElement0();
pair.getElement1();

不可变，只有一对!

对于Java这样的编程语言，大多数程序员用来表示类似对的数据结构的备用数据结构是两个数组，并且数据通过相同的索引访问

例如:http://www-igm.univ-mlv.fr/ lecroq /字符串/ node8.html # SECTION0080

这并不理想，因为数据应该绑定在一起，但结果也相当便宜。此外，如果你的用例需要存储坐标，那么最好构建自己的数据结构。

我的图书馆里就有这样的东西

public class Pair<First,Second>{.. }

根据Java语言的性质，我认为人们实际上并不需要Pair，通常他们需要的是一个接口。这里有一个例子:

interface Pair<L, R> {
    public L getL();
    public R getR();
}

所以，当人们想要返回两个值时，他们可以这样做:

... //Calcuate the return value
final Integer v1 = result1;
final String v2 = result2;
return new Pair<Integer, String>(){
    Integer getL(){ return v1; }
    String getR(){ return v2; }
}

This is a pretty lightweight solution, and it answers the question "What is the semantic of a Pair<L,R>?". The answer is, this is an interface build with two (may be different) types, and it has methods to return each of them. It is up to you to add further semantic to it. For example, if you are using Position and REALLY want to indicate it in you code, you can define PositionX and PositionY that contains Integer, to make up a Pair<PositionX,PositionY>. If JSR 308 is available, you may also use Pair<@PositionX Integer, @PositionY Ingeger> to simplify that.

编辑: 这里我应该指出的一点是，上面的定义显式地将类型参数名和方法名联系起来。这是对那些认为Pair缺乏语义信息的人的回答。实际上，getL方法的意思是“给我对应于类型参数L的类型的元素”，这确实意味着什么。

编辑: 下面是一个简单的实用程序类，可以让生活变得更简单:

class Pairs {
    static <L,R> Pair<L,R> makePair(final L l, final R r){
        return new Pair<L,R>(){
            public L getL() { return l; }
            public R getR() { return r; }   
        };
    }
}

用法:

return Pairs.makePair(new Integer(100), "123");