Вы можете достичь своих целей также с более скромными подходами ... если это игра в слова, то я подозреваю, что вы используете 27 букв алфавита. Предположим, что алфавит состоит не более чем из 32 букв, то есть 5 битов на букву. Затем вы можете втиснуть 12 букв (12 x 5 = 60 бит) в одну Java long , используя 5-битное / буквенное тривиальное кодирование.
Это означает, что на самом деле, если у вас нет более длинных слов, чем 12 букв / слов, вы можете просто представить свой словарь как набор длинных слов Java. Если у вас есть 250 000 слов, простое представление этого набора в виде единого отсортированного массива длин должно занять 250 000 слов x 8 байт / слово = 2 000 000 ~ 2 МБ памяти. Тогда поиск выполняется с помощью бинарного поиска, который должен быть очень быстрым, учитывая небольшой размер набора данных (менее 20 сравнений, так как 2 ^ 20 приводит к более чем одному миллиону).
Если у вас есть более длинные слова, чем 12 букв, то I сохранит слова из> 12 букв в другом массиве, где 1 слово будет представлено 2 каскадными последовательностями Java очевидным образом.
ПРИМЕЧАНИЕ: причина, по которой это работает и, вероятно, более компактно, чем три и, по крайней мере, очень проста в реализации, состоит в том, что словарь постоянен ... деревья поиска хороши, если вам нужно изменить набор данных, но если набор данных постоянен, вы часто можете выполнить простой бинарный поиск.