最大的问题可能是不能确保A和B上的不可变(参见如何确保类型参数是不可变的)，因此hashCode()在插入到集合后可能会为相同的Pair给出不一致的结果(这将给出未定义的行为，参见定义可变字段中的equals)。对于一个特定的(非泛型的)Pair类，程序员可以通过仔细选择a和B为不可变来确保不可变性。

不管怎样，从@PeterLawrey的回答中清除泛型的警告(java 1.7):

public class Pair<A extends Comparable<? super A>,
                    B extends Comparable<? super B>>
        implements Comparable<Pair<A, B>> {

    public final A first;
    public final B second;

    private Pair(A first, B second) {
        this.first = first;
        this.second = second;
    }

    public static <A extends Comparable<? super A>,
                    B extends Comparable<? super B>>
            Pair<A, B> of(A first, B second) {
        return new Pair<A, B>(first, second);
    }

    @Override
    public int compareTo(Pair<A, B> o) {
        int cmp = o == null ? 1 : (this.first).compareTo(o.first);
        return cmp == 0 ? (this.second).compareTo(o.second) : cmp;
    }

    @Override
    public int hashCode() {
        return 31 * hashcode(first) + hashcode(second);
    }

    // TODO : move this to a helper class.
    private static int hashcode(Object o) {
        return o == null ? 0 : o.hashCode();
    }

    @Override
    public boolean equals(Object obj) {
        if (!(obj instanceof Pair))
            return false;
        if (this == obj)
            return true;
        return equal(first, ((Pair<?, ?>) obj).first)
                && equal(second, ((Pair<?, ?>) obj).second);
    }

    // TODO : move this to a helper class.
    private boolean equal(Object o1, Object o2) {
        return o1 == o2 || (o1 != null && o1.equals(o2));
    }

    @Override
    public String toString() {
        return "(" + first + ", " + second + ')';
    }
}

补充/更正非常欢迎:)特别是我不太确定我使用Pair<?, ? >。

有关为什么这种语法的更多信息，请参阅确保对象实现可比和详细解释如何在Java中实现一个通用的max(可比a，可比b)函数?

Apache Commons Lang 3.0+有几个Pair类: http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/tuple/package-summary.html

许多人都张贴对代码，可用作地图中的键…如果您试图使用一对作为哈希键(常用习语)，请务必查看Guava的Table<R,C,V>: http://code.google.com/p/guava-libraries/wiki/NewCollectionTypesExplained#Table。对于图边，他们给出了下面的用法示例:

Table<Vertex, Vertex, Double> weightedGraph = HashBasedTable.create();
weightedGraph.put(v1, v2, 4);
weightedGraph.put(v1, v3, 20);
weightedGraph.put(v2, v3, 5);

weightedGraph.row(v1); // returns a Map mapping v2 to 4, v3 to 20
weightedGraph.column(v3); // returns a Map mapping v1 to 20, v2 to 5

Table将两个键映射到一个值，并单独为这两种类型的键提供有效的查找。我已经开始使用这个数据结构，而不是Map<Pair<K1,K2>， V>在我的代码的许多部分。有数组、树和其他用于密集和稀疏使用的实现，可以指定您自己的中间映射类。

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

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

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

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

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

最大的问题可能是不能确保A和B上的不可变(参见如何确保类型参数是不可变的)，因此hashCode()在插入到集合后可能会为相同的Pair给出不一致的结果(这将给出未定义的行为，参见定义可变字段中的equals)。对于一个特定的(非泛型的)Pair类，程序员可以通过仔细选择a和B为不可变来确保不可变性。

不管怎样，从@PeterLawrey的回答中清除泛型的警告(java 1.7):

public class Pair<A extends Comparable<? super A>,
                    B extends Comparable<? super B>>
        implements Comparable<Pair<A, B>> {

    public final A first;
    public final B second;

    private Pair(A first, B second) {
        this.first = first;
        this.second = second;
    }

    public static <A extends Comparable<? super A>,
                    B extends Comparable<? super B>>
            Pair<A, B> of(A first, B second) {
        return new Pair<A, B>(first, second);
    }

    @Override
    public int compareTo(Pair<A, B> o) {
        int cmp = o == null ? 1 : (this.first).compareTo(o.first);
        return cmp == 0 ? (this.second).compareTo(o.second) : cmp;
    }

    @Override
    public int hashCode() {
        return 31 * hashcode(first) + hashcode(second);
    }

    // TODO : move this to a helper class.
    private static int hashcode(Object o) {
        return o == null ? 0 : o.hashCode();
    }

    @Override
    public boolean equals(Object obj) {
        if (!(obj instanceof Pair))
            return false;
        if (this == obj)
            return true;
        return equal(first, ((Pair<?, ?>) obj).first)
                && equal(second, ((Pair<?, ?>) obj).second);
    }

    // TODO : move this to a helper class.
    private boolean equal(Object o1, Object o2) {
        return o1 == o2 || (o1 != null && o1.equals(o2));
    }

    @Override
    public String toString() {
        return "(" + first + ", " + second + ')';
    }
}

补充/更正非常欢迎:)特别是我不太确定我使用Pair<?, ? >。

有关为什么这种语法的更多信息，请参阅确保对象实现可比和详细解释如何在Java中实现一个通用的max(可比a，可比b)函数?

@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个值的类至少仍然有意义。