В Judge има две "състезания" с тази задача: Java и C#. 

Глеадйки резултатите от изпита и упражненията по Java, няма нито едино решение, което да вземе 100/100 (до 91).

За C# има по един резултат 100/100 на изпита и на упражненията.

Следва да се отбележи, че дори и решението на Lazii, за което предполагам, че референтното, не е взело 100 точки на Java.

Предполагам, че за този изпит се е случило това, което се случва открай време с този курс - задачите се пишат на C# и в последния момент се адаптират за Java, при което се случва едно от следните неща:

1. Решение, при което се използва неоптимална за проблема структура взема 100 точки, защото не са сложили достатъчно стриктни ограничения

2. Колкото и да се оптимизира дадено решение, не успява да вземе 100 точки, защото ограниченията са сложени "наизуст", без да има референтно решение

3. Има проблеми със скелета, тестовете и качеството на кода, защото е "преписан" от C# решението

Ако качите решението си мога да го по прегледам за възможни оптимизации, но най-вероятно проблемът е в някоя от точките по-горе.

Прегледах скелета за Java и открих няколко грешки в тестовете.

OlympicsImplCorrectnessTest.java - в два от тестовете липсва assert, т.е. тестът винаги минава локално, но в Judge единият от тях фейлва (явно е оправен в движение)

• contains_should_return_true_with_valid_data()
• contains_should_return_false_with_invalid_data()

OlympicsImplCorrectnessTest.java - тук проблемите са повече 

• тестовете, които проверяват за използвана памет имат проверка и за минимална памет ( > 100), но начинът по който я отчитат не е надежден, защото свободната памет се промня динамично заради Garabage Collectora-a и е напълно възможно свободната памет след като сме създали 1000000 обекта де е дори повече, отколкото е била преди това. Възможните варианти за заобикаляне на този проблем (произволно фейлване на такъв тест) са или да се махне проверката за долна граница (най-добре), или да се форсне garabage collection-a преди всеки тест (в setUp() се добавя Runtime.getRuntime().gc())
• много тестове имат сетнат timeout, например @Test(timeout = 500), въпреки че теста трябва да провери скоростта на конкретна операция (вътре в метода се засича времето ѝ с System.currentTimeMillis()). Проблемът е, че в някои методи се създават 1_000_000 тестови обекта още преди да бъдат използвани от тестваната система, а времето за създаването им отнема от цялото време за метода (примерно 500 мс) и това води до random fail на някои от тези тестове. За избягване на този проблем не трябва да има таймаут на метода или тестовите данни трябва да бъдат създадени преди това
• решение само с 2 HashMap-а и използването на Stream API за отделните методи взема 91/100 точки, а ако се оправят горните проблеми в тестовете най-вероятно ще вземе и 100/100, т.е. тестовете не налагат използването на комбинация от различни контейнери за да се постигне оптимално бързодействие

Edit:

В това видео се опитват да решат проблема с тази задача и се вижда, че тест №14 e addCompetitor_1_000_000_competitors_memory_usage(), но кодът му се различава от този в скелета: липсва timeout, създават се 500_000 competitors проверката за памет е от 50 до 120MB. Решението най-вероятно ще мине, ако се премахне долната граница за паметта в assert-а.