如果你的set实际上是一个NavigableSet<Foo>(例如TreeSet)，并且Foo实现Comparable<Foo>，你可以使用

Foo bar = set.floor(foo); // or .ceiling
if (foo.equals(bar)) {
    // use bar…
}

(感谢@eliran-malka的评论。)

是的，使用HashMap…但是以一种专门的方式:我预见到试图使用HashMap作为伪集的陷阱是Map/Set的“实际”元素和“候选”元素之间可能的混淆，即用于测试是否已经存在相等元素的元素。这不是万无一失的方法，但能让你远离陷阱:

class SelfMappingHashMap<V> extends HashMap<V, V>{
    @Override
    public String toString(){
        // otherwise you get lots of "... object1=object1, object2=object2..." stuff
        return keySet().toString();
    }

    @Override
    public V get( Object key ){
        throw new UnsupportedOperationException( "use tryToGetRealFromCandidate()");
    }

    @Override
    public V put( V key, V value ){
       // thorny issue here: if you were indavertently to `put`
       // a "candidate instance" with the element already in the `Map/Set`: 
       // these will obviously be considered equivalent 
       assert key.equals( value );
       return super.put( key, value );
    }

    public V tryToGetRealFromCandidate( V key ){
        return super.get(key);
    }
}

然后这样做:

SelfMappingHashMap<SomeClass> selfMap = new SelfMappingHashMap<SomeClass>();
...
SomeClass candidate = new SomeClass();
if( selfMap.contains( candidate ) ){
    SomeClass realThing = selfMap.tryToGetRealFromCandidate( candidate );
    ...
    realThing.useInSomeWay()...
}

但是…你现在希望候选对象以某种方式自毁，除非程序员立即将其放入Map/Set…你会希望包含“玷污”候选对象，除非它加入Map，否则任何对它的使用都会使它“被诅咒”。也许你可以让SomeClass实现一个新的Taintable接口。

更令人满意的解决方案是GettableSet，如下所示。然而，要做到这一点，你必须负责SomeClass的设计，以使所有构造函数都不可见(或者…能够并且愿意为它设计和使用包装类):

public interface NoVisibleConstructor {
    // again, this is a "nudge" technique, in the sense that there is no known method of 
    // making an interface enforce "no visible constructor" in its implementing classes 
    // - of course when Java finally implements full multiple inheritance some reflection 
    // technique might be used...
    NoVisibleConstructor addOrGetExisting( GettableSet<? extends NoVisibleConstructor> gettableSet );
};

public interface GettableSet<V extends NoVisibleConstructor> extends Set<V> {
    V getGenuineFromImpostor( V impostor ); // see below for naming
}

实现:

public class GettableHashSet<V extends NoVisibleConstructor> implements GettableSet<V> {
    private Map<V, V> map = new HashMap<V, V>();

    @Override
    public V getGenuineFromImpostor(V impostor ) {
        return map.get( impostor );
    }

    @Override
    public int size() {
        return map.size();
    }

    @Override
    public boolean contains(Object o) {
        return map.containsKey( o );
    }

    @Override
    public boolean add(V e) {
        assert e != null;
        V result = map.put( e,  e );
        return result != null;
    }

    @Override
    public boolean remove(Object o) {
        V result = map.remove( o );
        return result != null;
    }

    @Override
    public boolean addAll(Collection<? extends V> c) {
        // for example:
        throw new UnsupportedOperationException();
    }

    @Override
    public void clear() {
        map.clear();
    }

    // implement the other methods from Set ...
}

你的NoVisibleConstructor类看起来是这样的:

class SomeClass implements NoVisibleConstructor {

    private SomeClass( Object param1, Object param2 ){
        // ...
    }

    static SomeClass getOrCreate( GettableSet<SomeClass> gettableSet, Object param1, Object param2 ) {
        SomeClass candidate = new SomeClass( param1, param2 );
        if (gettableSet.contains(candidate)) {
            // obviously this then means that the candidate "fails" (or is revealed
            // to be an "impostor" if you will).  Return the existing element:
            return gettableSet.getGenuineFromImpostor(candidate);
        }
        gettableSet.add( candidate );
        return candidate;
    }

    @Override
    public NoVisibleConstructor addOrGetExisting( GettableSet<? extends NoVisibleConstructor> gettableSet ){
       // more elegant implementation-hiding: see below
    }
}

PS这样的NoVisibleConstructor类的一个技术问题:它可能会被反对，这样的类本质上是final的，这可能是不可取的。实际上，你总是可以添加一个虚拟的无参数保护构造函数:

protected SomeClass(){
    throw new UnsupportedOperationException();
}

．.． 这样至少可以让一个子类编译。然后，您必须考虑是否需要在子类中包含另一个getOrCreate()工厂方法。

最后一步是为你的集合成员创建一个抽象基类(注意“element”表示列表，“member”表示集合)，就像这样(如果可能的话——同样，使用包装器类时，类不在你的控制之下，或者已经有一个基类，等等)，以最大限度地隐藏实现:

public abstract class AbstractSetMember implements NoVisibleConstructor {
    @Override
    public NoVisibleConstructor
            addOrGetExisting(GettableSet<? extends NoVisibleConstructor> gettableSet) {
        AbstractSetMember member = this;
        @SuppressWarnings("unchecked") // unavoidable!
        GettableSet<AbstractSetMembers> set = (GettableSet<AbstractSetMember>) gettableSet;
        if (gettableSet.contains( member )) {
            member = set.getGenuineFromImpostor( member );
            cleanUpAfterFindingGenuine( set );
        } else {
            addNewToSet( set );
        }
        return member;
    }

    abstract public void addNewToSet(GettableSet<? extends AbstractSetMember> gettableSet );
    abstract public void cleanUpAfterFindingGenuine(GettableSet<? extends AbstractSetMember> gettableSet );
}

．.． 用法是相当明显的(在你的SomeClass的静态工厂方法中):

SomeClass setMember = new SomeClass( param1, param2 ).addOrGetExisting( set );

如果你看一下java.util.HashSet实现的前几行，你会看到:

public class HashSet<E>
    ....
    private transient HashMap<E,Object> map;

HashSet在内部使用HashMap，这意味着如果你直接使用HashMap并使用与键相同的值，你会得到你想要的效果，并节省一些内存。

要准确回答“为什么Set不提供获取等于另一个元素的元素的操作?”这个问题，答案可能是:因为集合框架的设计者不是很有前瞻性。他们没有预料到您非常合理的用例，天真地试图“建模数学集合抽象”(从javadoc)，只是忘记添加有用的get()方法。

现在回到隐含的问题“如何获得元素”:我认为最好的解决方案是使用Map<E,E>而不是Set<E>来将元素映射到它们自己。通过这种方式，您可以有效地从“set”中检索元素，因为Map的get()方法将使用有效的哈希表或树算法查找元素。如果愿意，可以编写自己的Set实现，提供额外的get()方法，封装Map。

以下答案在我看来是错误的:

“您不需要获取元素，因为您已经有了一个相等的对象”:断言是错误的，正如您在问题中已经表明的那样。两个相等的对象仍然可以具有与对象相等无关的不同状态。目标是访问Set中包含的元素的状态，而不是用作“查询”的对象的状态。

"You have no other option but to use the iterator": that is a linear search over a collection which is totally inefficient for large sets (ironically, internally the Set is organized as hash map or tree that could be queried efficiently). Don't do it! I have seen severe performance problems in real-life systems by using that approach. In my opinion what is terrible about the missing get() method is not so much that it is a bit cumbersome to work around it, but that most programmers will use the linear search approach without thinking of the implications.

遵循可以是一种方法

   SharedPreferences se_get = getSharedPreferences("points",MODE_PRIVATE);
   Set<String> main = se_get.getStringSet("mydata",null);
   for(int jk = 0 ; jk < main.size();jk++)
   {
      Log.i("data",String.valueOf(main.toArray()[jk]));
   }

如果你想要HashSet中的第n个元素，你可以使用下面的解决方案， 这里我在HashSet中添加了ModelClass对象。

ModelClass m1 = null;
int nth=scanner.nextInt();
for(int index=0;index<hashset1.size();index++){
    m1 = (ModelClass) itr.next();
    if(nth == index) {
        System.out.println(m1);
        break;
    }
}