Помогите Метод запуска асинхронного потока Bukkit работает некорректно?

Статус
Закрыто для дальнейших ответов.

Абсик

Активный участник
Пользователь
Баллы
76
Имя в Minecraft
Abcik
Всем привет!

Столкнулся с проблемой, что метод Bukkit.getScheduler().runTaskAsynchronously() работает как-то некорректно. Я так и не понял в чем проблема, но когда я создавал одновременно ~2000 потоков в сек (1000 на бакките, и 1000 на банджикорде (BungeeCord.getInstance().getScheduler().runAsync)) У меня тупо крашился спигот сервер. Затем я решил на банджикорде заменить метод на new Thread() , краш спигота пропал, но так как на спиготе я всё-ещё использовал метод Bukkit.getScheduler().runTaskAsynchronously() данные, которые я отправлял из этого потока иногда как-будто куда-то девались, просто пропадали, примерно каждый 5-ти тысячный поток... (Когда я везде заменил методы на new Thread() - все проблемы исчезли)В общем, тут у меня созрел вопрос, что отличает методы банджикорда, спигота, от обычного new Thread(), и могу ли я везде использовать new Thread() ?

Прежде чем написать сюда, я нашел лишь одну тему по этому вопросу, там все говорят использовать метод баккита, но почему не особо понятно, к тому же он хуже справляется с задачами. В общем, жду разъяснения ситуации...
 
Всем привет!

Столкнулся с проблемой, что метод Bukkit.getScheduler().runTaskAsynchronously() работает как-то некорректно. Я так и не понял в чем проблема, но когда я создавал одновременно ~2000 потоков в сек (1000 на бакките, и 1000 на банджикорде (BungeeCord.getInstance().getScheduler().runAsync)) У меня тупо крашился спигот сервер. Затем я решил на банджикорде заменить метод на new Thread() , краш спигота пропал, но так как на спиготе я всё-ещё использовал метод Bukkit.getScheduler().runTaskAsynchronously() данные, которые я отправлял из этого потока иногда как-будто куда-то девались, просто пропадали, примерно каждый 5-ти тысячный поток... (Когда я везде заменил методы на new Thread() - все проблемы исчезли)В общем, тут у меня созрел вопрос, что отличает методы банджикорда, спигота, от обычного new Thread(), и могу ли я везде использовать new Thread() ?

Прежде чем написать сюда, я нашел лишь одну тему по этому вопросу, там все говорят использовать метод баккита, но почему не особо понятно, к тому же он хуже справляется с задачами. В общем, жду разъяснения ситуации...
Разница в том, что шедулер использует пул потоков, который в свою очередь запускает столько потоков, сколько может и вероятно он отклоняет задачи, если они превышают заданный размер пула.
new Thread() создает абсолютно новый поток без ограничений. Таких можешь создать сколько угодно, пока не закончится память. Но этого делать не рекомендуется если это мелкие задачи.
 
Они что, не очищаются из памяти после завершения кода? (Если нет, то как очистить их вручную или типа того?)
Если их создать в один момент больше чем хватит памяти то сборщик мусора просто не успеет очистить память.
Да и создание нового потока требует много ресурсов.
 
Последнее редактирование:
Решил я проверить... И ещё раз убедился, что баккит метод полный ужас, работает, оказывается, в 1000 раз медленнее!

Посмотреть вложение 59531

Посмотреть вложение 59532
Когда ты добавляешь задачу в любой шедулер (даже в асинхронный), эта задача будет обработана в следующем тике в основном потоке и тогда будет запущена там же или асинхронно. По этой причине такая задержка.
 
Решил я проверить... И ещё раз убедился, что баккит метод полный ужас, работает, оказывается, в 1000 раз медленнее!
А ничего что BukkitScheduler работает на тиках сервера? 50mc = 1 тик. Об этом даже мой кашак знает.
 
Не уверен, что Thread лучше. Шедулер не просто так сделан.
И вопрос - какие задачи стоят?
 
Когда ты добавляешь задачу в любой шедулер (даже в асинхронный), эта задача будет обработана в следующем тике в основном потоке и тогда будет запущена там же или асинхронно. По этой причине такая задержка.
А ничего что BukkitScheduler работает на тиках сервера? 50mc = 1 тик. Об этом даже мой кашак знает.
А, точно... Но сути дела не меняет. Зачем мне зря ждать следующего тика то? И это единственная вещь чем баккитовский метод отличается?

Не уверен, что Thread лучше. Шедулер не просто так сделан.
И вопрос - какие задачи стоят?
Задачи самые резные, например, обмен пакетами.
 
А, точно... Но сути дела не меняет. Зачем мне зря ждать следующего тика то? И это единственная вещь чем баккитовский метод отличается?


Задачи самые резные, например, обмен пакетами.
Обычно такое делается одним потоком с while true.
 
Задачи самые резные, например, обмен пакетами.
Для этого уже есть готовый plugin message, а не твой костыль с 2к трейдами. Ты только уменьшаешь производительность таким числом трейдов. В том же netty не просто так выделено всего 4 трейда.
 
В общем понятно. Никто толком не может обосновать почему вредно юзать не баккитовский метод. Поэтому, буду юзать его, так как он удобнее и быстрее. Если что-то пойдёт не так - как раз и узнаю почему его не рекомендуют. Всем спасибо.
 
В общем понятно. Никто толком не может обосновать почему вредно юзать не баккитовский метод. Поэтому, буду юзать его, так как он удобнее и быстрее. Если что-то пойдёт не так - как раз и узнаю почему его не рекомендуют. Всем спасибо.
В случае с шедулером, менеджментом задач занимается сам баккит - ошибками, запуском и отключением. Как упомянули ранее, баккит использует пул потоков - это значит, что при завершении задачи, поток, возможно, будет использован снова, а не создан новый (что влияет на производительность всего сразу)
Никто не останавливает взять, да пустить собственный поток - единственное, не стоит забывать нормально остановить его на onDisable(). Однако, как упомянули ранее, создание десятков/сотен потоков налету лишь нагрузит машину.
 
Статус
Закрыто для дальнейших ответов.
Назад
Верх