TreeSet не добавляет все элементы?

Вы почти наверняка создаете повторяющиеся объекты Person.

В своем комментарии вы сказали, что каждый человек генерируется случайным образом из пола, имени и фамилии из текстового файла, содержащего «сотни» имен и возраст. Допустим, есть два варианта пола, по 300 вариантов имени и фамилии и 100 возможных значений возраста. Это в общей сложности 18 000 000 возможных уникальных людей.

Далее предположим, что equals() правильно реализован на этом объекте, то есть правильно проверяет все эти поля.

Вы создаете 1 000 000 уникальных людей, используя случайные характеристики из 18 000 000 возможностей.

Интуитивно вы можете подумать, что существует «мизерная» вероятность дубликатов, но на самом деле вероятность существования дубликатов составляет около 1,0 минус эпсилон. Это известно как проблема дня рождения или иногда парадокс дня рождения.

Как указано на этой странице, вероятность столкновения между любыми двумя вариантами примерно равна

1 - ((d-1) / d) ^ n(n-1)/2

где d — количество значений в домене, а n — количество сделанных выборов. Я не совсем уверен, но со значениями d = 18 000 000 и n = 1 000 000, я думаю, получится примерно 1.0 - 1E-323. (EDIT: правильное значение — около 1.0 - 2.84E-12294. Это чертовски близко к единице.)

Ожидаемое количество столкновений при таком выборе определяется по следующей формуле:

n - d + d * ((d-1) / d) ^ n

Если d = 18 000 000 и n = 1 000 000, то получается примерно 27 000. То есть в среднем вы получите 27 000 столкновений. Это довольно близко к количеству «отсутствующих» элементов в вашем TreeSet, именно так будут проявляться коллизии. Я признаю, что подбирал свои цифры так, чтобы они были довольно близки к тому, что вы видите, но мои предположения и результаты вполне правдоподобны.

Вам нужно переосмыслить способ генерации данных, которые вы сохраняете в наборе.

с высокой степенью уверенности могу сказать, что вы добавляете дубликаты в свой TreeSet. если вы мне не верите, просто добавьте числа к treeSet, убедитесь, что числа от 1 до 1000000, тогда вы увидите, что получите именно то, что ожидаете.

Как только вы рассеете свои сомнения, давайте попробуем отсортировать ваш класс People.

Добавьте следующее в свой класс людей:

int id;    //ensure that every people object you create has different id. e.g. 1 to 10m;

@override
public boolean equals(Object o){
  if(this.getClass()!=o.getClass()) return false;
  else return (People (o)).id==this.id;
}

@override
public int hashCode(){
 return id;
}

теперь начните добавлять вещи в свой набор. :)

ПРИМЕЧАНИЕ Этот код является просто примером простого подхода к созданию различных классов людей. Это хороший подход к тестированию с помощью treeSet и т. Д., Но это не рекомендуется для реальных проблем.

Убедитесь, что метод compareTo() в вашем классе People реализован правильно. В Comparable javadoc указано следующее:

Настоятельно рекомендуется (хотя и не требуется), чтобы естественные упорядочения соответствовали равным. Это так, потому что отсортированные наборы (и отсортированные карты) без явных компараторов ведут себя «странно», когда они используются с элементами (или ключами), чей естественный порядок несовместим с равными. В частности, такой отсортированный набор (или отсортированная карта) нарушает общий контракт для набора (или карты), который определен в терминах метода equals.

Например, если добавить два ключа a и b таким образом, что (!a.equals(b) && a.compareTo(b) == 0) к отсортированному набору, который не использует явный компаратор, вторая операция add вернет false (и размер отсортированного набора не увеличится), поскольку a и b эквивалентны с точки зрения отсортированного набора.