В последнем примере, пока один поток будет висеть в выполнении calculateExpensive(key), ничего не мешает другим потокам тоже получить null в get и тоже упасть в вычисление. Тогда уже лучше использовать computeIfAbsent, который гарантирует только один вызов на ключ, судя по документации, а то, что кто-то в лямбду добавляет side-effectы, это уже проблема не ConcurrentHashMap, а разработчика. Да и не вижу в чем проблема долгих исчислений, это не блокирует всю таблицу, проблема лишь в том, что поток занят и наверное нужно вообще переосмысливать идею пользоваться лишь одной таблицой для приложений с высокой нагрузкой.
Это было очень приятной новостью для меня, я легко смог перейти с OpenAI на Deepseek в своих мелких проектах. Но я заметил, что там много проблем. R1 не поддерживает tool calls, не поддерживает диалог, structured output очень сильно тупит и часто выдает не валидный JSON. А V3 уходит в бесконечный цикл при попытке сделать tool call, этой проблеме уже месяц, висит у них на гитхабе.
К слову, ollama тоже имеет слой совместимости с OpenAI api...
Если чанки не прогружены в конечной точке телепортации, то внезапный телепорт туда вызовет панику небольшую для сервера, на спиготе их желательно заранее прогрузить, а на бумаге использовать teleportAsync.
Частицы так спавнить вполне себе ок, главное не забывать, что с главного потока использовать sleep может быть очень больно (в вашем случае 23 наносекунды - фигня).
Location сериализируется и десериализируется без проблем уже встроенным ридером yaml.
Ну и да, у спигота довольно хорошая поддержка работы с файлами конфигураций. Есть методы для загрузки дефолтного файла из jar, есть методы для установки дефолтных значений и даже работа с комментами.
Ах да, проверка местоположения игрока это очень дешёвая операция, её вполне можно вызывать на событии движения как только игрок чуть ниже минимальной координаты. Ой, ещё забыл, начиная с 1.18 разные миры имеют разную минимальную высоту, которую лучше проверять :)
В последнем примере, пока один поток будет висеть в выполнении calculateExpensive(key), ничего не мешает другим потокам тоже получить null в get и тоже упасть в вычисление. Тогда уже лучше использовать computeIfAbsent, который гарантирует только один вызов на ключ, судя по документации, а то, что кто-то в лямбду добавляет side-effectы, это уже проблема не ConcurrentHashMap, а разработчика. Да и не вижу в чем проблема долгих исчислений, это не блокирует всю таблицу, проблема лишь в том, что поток занят и наверное нужно вообще переосмысливать идею пользоваться лишь одной таблицой для приложений с высокой нагрузкой.
Это было очень приятной новостью для меня, я легко смог перейти с OpenAI на Deepseek в своих мелких проектах. Но я заметил, что там много проблем. R1 не поддерживает tool calls, не поддерживает диалог, structured output очень сильно тупит и часто выдает не валидный JSON. А V3 уходит в бесконечный цикл при попытке сделать tool call, этой проблеме уже месяц, висит у них на гитхабе.
К слову, ollama тоже имеет слой совместимости с OpenAI api...
Конечно! Чем больше разработчиков, тем больше плагинов и тем довольнее игроки!
Если чанки не прогружены в конечной точке телепортации, то внезапный телепорт туда вызовет панику небольшую для сервера, на спиготе их желательно заранее прогрузить, а на бумаге использовать teleportAsync.
Частицы так спавнить вполне себе ок, главное не забывать, что с главного потока использовать sleep может быть очень больно (в вашем случае 23 наносекунды - фигня).
Location сериализируется и десериализируется без проблем уже встроенным ридером yaml.
Ну и да, у спигота довольно хорошая поддержка работы с файлами конфигураций. Есть методы для загрузки дефолтного файла из jar, есть методы для установки дефолтных значений и даже работа с комментами.
Ах да, проверка местоположения игрока это очень дешёвая операция, её вполне можно вызывать на событии движения как только игрок чуть ниже минимальной координаты. Ой, ещё забыл, начиная с 1.18 разные миры имеют разную минимальную высоту, которую лучше проверять :)