Александр

Рискну ответить, хотя вопрос на самом деле не простой, т к у всех всё очень индивидуально. Вам стоит не просто решать задачи одну за одной, а начать усложнять их самостоятельно. Как это работает: вы придумываете дополнительные условия, а ваш мозг сам подсказывает как это можно реализовать. Т к придумали вы это сами, мозг может уже изначально знать решение на подсознательном уровне. Дальнейшая реализация решения в коде закрепляет навык. Вы начинаете как бы представлять как работает код внутри.
Другие варианты действий:
1. Разбор чужих решений до полного понимания их работы. Берете и буквально на бумаге расписываете всё, что происходит на каждой итерации цикла - все переменные и как сработают условия. Эта техника развивает не только внутреннее представление работы кода, но и навык чтения чужого кода.
2. Более простой метод: тоже самоме, что и п1, но с использованием отладчика. На каждой итерации цикла смотрите состояние программы и у вас должны появиться мысли, что и куда нужно там добавить, что бы получить нужный эффект. Это "упражнение" за одно развивает навык отладки.
3. Не зацикливайтесь на конечном правильном решении, разбивайте задачу на малые итерации. Из вашего же примера: не можете сообразить как получить второе значение, выведите первое! Затем прогоните программу через отладчик (ну или "через бумажку") и попробуйте понять чего не хватает и где.

Не сказано главного: какого размера map ? т е сколько объектов ? десятки, сотни, десятки тысяч ?
Второе, что не сказано - с какой частотой надо принудительно обновлять, и с какой частотой валятся события на обновление. Одно дело раз в 20мс другое дело раз в минуту. Либо же надо поддерживать эту структуру сортированной при любом обновлении ?
Wataru вам предлагает вполне ризонно список использовать. Если у вас ключ - это время, то вам мап не нужен вообще. Возьмите очередь (Deque) и пихайте только что обновленный объект в конец.
Для принудительного обновления: берете первые 4 из очереди и раздаете в потоки.
Для обновления по событию: придется сначала найти объект в очереди. Для этого пройтись по ней итератором. Это позволяет, например, ConcurrentLinkedDeque Итератор там потокобезопасен, но не итерирует вставки, которые были после взятия итератора. Т е может быть такой момент, что пока вы итерируете, придет ещё одно событие и всунет вам новый объект который в итератор не попадет. Либо ваш поток обновит порядок, а итератор этого не увидит, поэтому приходящее событие нужно будет ручками синхронизировать с выдачей элементов на принудительное обновление. И что-то лучшее боюсь тут сложно придумать. Дайте больше информации о масштабах задачи. Если объектов много, то возможно вместо простой очереди использовать какой-нибудь TreeMap или ещё что-то такое, где есть доступ по индексу.

Откуда вы взяли этот useSSL=false ? Вот дока от микрософт по их jdbc драйверу https://docs.microsoft.com/ru-ru/sql/connect/jdbc/... Там никаких useSSL нет. За то есть encryption и trustServerCertificate Там даны различные варианты с описанием. Попробуйте их.

В вопросе подробностей маловато. Какая база предполагается будет реально хранить этот entity ? Если это классическая реляционка, то на мой взгляд лучше хранить как List или Set. Потенциально Map мог бы дать возможность получать доступ к элементу заказа по его номеру (или какому то ключу) за O(1) время (т е за константное время) Это давало бы выигрыш в случае очень больших заказов с большим количеством элементов. Но поскольку реально значение хранит база, то, если необходимо выполнить поиск одного элемента, не подтягивая весь список в память, это можно сделать выборкой по индексу. (например id заказа + id элемента или же просто "сквозной" id элемента) Если же заказы не будут превышать 10-50 элементов, то и вообще нет смысла заморачиваться и надо выбирать наиболее простой способ, т е List. Уже в самом коде можно организовать доступ к этому полю как угодно. Из-за малого размера списка проблем с производительностью быть не должно.