считать большой файл.

Большой объём файла (т. е. не помещающийся в оперативную память) лишает возможности произвести сортировку целиком в оперативке. Значит текстовый формат файла для сортировки не подойдёт, необходим произвольный доступ. С другой стороны, хотелось бы максимально снизить количество обращений к диску (т. е. какое-нибудь кэширование) , но это ограничивает "произвольность" доступа.

Ограничим фантазию выбора:
Естественные ограничения: сортировать в оперативке целиком нельзя, слишком большой объём.
Дополнительные ограничения: алгоритм не должен обращаться последовательно в несколько удалённых друг от друга мест файла (чтобы кэширование имело эффект) .
Это лаба: Для простоты использовать уже готовый алгоритм (причём простой, без модификаций) , не комбинировать алгоритмы, выполнять всё в одном потоке (thread).

java - Для работы с большими файлами можно использовать прямое отображение файла в память (java.nio.MappedByteBuffer)
В качестве алгоритма взять Merge sort - довольно быстрый O(n·lg(n)), потребует дополнительно места на диске в объёме n/2. Кэширование не пострадает (этот алгоритм использовался даже для сортировки данных на магнитной ленте) .

смотреть: http : // en . wikipedia . org / wiki / Sorting_algorithm ; http : // en . wikipedia . org / wiki / Merge_sort ; http : // www . sorting-algorithms . com / merge-sort

64-битный компилятор и большой файл подкачки спасут гиганта мысли? Это если в лоб.
Если не в лоб, то надо:

1. Пройтись по всему большому файлу, узнать, каков диапазон значений.
2. Поделить диапазон на N равных частей.
3. Пройтись еще раз и слить все в N файлов.
4. Отсортировать каждый из файлов в отдельности (тут бы весело это дело распараллелить, но мы помним, что у нас мало оперативы, поэтому не параллелим) .
5. Слить получившиеся файлы опять в один.

Сие работает при более-менее ровном распределении сортируемых значений, если оно не такое - надо "по-умному" делить диапазон. Впрочем, это не слишком сложно. Удачи.