Помогите Аналог шедулеров.. Много шедулеров

Lisenochek · 18 сен 2016

Всем привет. У меня есть плагин, в котором нужно реализовать некоторые циклические действия (отбирание здоровья и т.д), но проблема в том, что несколько таких шедулеров кушают много ресурсов сервера. Есть ли идеи, как можно было бы эти шедулеры оптимизировать или есть аналоги.

Я знаю, что есть тред (Thread), но если выполнять действия в асинхронном потоке, то будет выдавать предупреждения в консоли. Решается конечно же еще одним шедулером внутри, в котором и вписывается все эти действия, но это равноценно обычному шедулеру.

Dereku · 18 сен 2016

Достаточно одного шедулера. Почти во всём.

Lisenochek · 18 сен 2016

Dereku сказал(а):
Достаточно одного шедулера. Почти во всём.

Просвети, как мне выполнять все циклические действия с помощью одного шедулера

Dereku · 18 сен 2016

Lisenochek сказал(а):
Просвети, как мне выполнять все циклические действия с помощью одного шедулера

А зачем мне давать тебе рыбку, когда есть удочки?

Lisenochek · 18 сен 2016

Dereku сказал(а):
А зачем мне давать тебе рыбку, когда есть удочки?

Просто я тоже об этом задумывался, но как реализовывать... *пожал плечами*

Dereku · 18 сен 2016

Lisenochek сказал(а):
Просто я тоже об этом задумывался, но как реализовывать... *пожал плечами*

Окей, рыбка: Есть у нас лист с задачами. Каждая задача имеет тип и собственный "таймер". А этот самый таймер тикает наш шедулер. И если у нас на таймере нулики - выполняем задачу и сообщаем о том, что задачу выполнили, можно с ней что то делать.
Это как один из быстрореализуемых вариантов. Конечно, не без урона производительности (правда, он будет заметен когда у нас более 10к задач), но всё же.

Lisenochek · 18 сен 2016

Буду пробовать...

Dereku сказал(а):
Окей, рыбка: Есть у нас лист с задачами. Каждая задача имеет тип и собственный "таймер". А этот самый таймер тикает наш шедулер. И если у нас на таймере нулики - выполняем задачу и сообщаем о том, что задачу выполнили, можно с ней что то делать.
Это как один из быстрореализуемых вариантов. Конечно, не без урона производительности (правда, он будет заметен когда у нас более 10к задач), но всё же.

Понял только одно. Регаем шедулер, там вызываем нашу задачу, а как установить тики на задачу - не знаю.

ql_Nik_lp · 18 сен 2016

Учиться думать, и попробовать решить самому, в первую очередь. Один раз сам решишь - на годы запомнишь.
Если таки сложно, и самому ну никак не удалось, примерно распишу тебе вариант. Он внизу, белым по белому.
Создаешь некий абстра...ктный класс с двумя инт-полями и методами аля update() и execute() первое поле - откат, второе - текущий таймер
Апдейт следит за таймером и коль что вызывает execute, сам экзекьют ты переопределяешь в наследниках.
Можешь туда передавать еще что-то, или вообще как душе угодно.

_MediaNik_ · 18 сен 2016

ql_Nik_lp сказал(а):
Создаешь некий абстра...ктный класс с двумя инт-полями и методами аля update() и execute() первое поле - откат, второе - текущий таймер
Апдейт следит за таймером и коль что вызывает execute, сам экзекьют ты переопределяешь в наследниках.
Можешь туда передавать еще что-то, или вообще как душе угодно.

Моя твоЯ НЕ понимать!!1

Reality_SC · 18 сен 2016

Ни разу не встречался с задачами, когда нужно использовать/регистрировать свой шедулер.
Мне всегда хватало одного, стандартного, который доступен по getServer().getScheduler().
Он уже есть и уже умеет всё, что как мне кажется нужно остальным (не считая мега-проектов) — выполнять посланный в него код сразу, с задержкой, или регулярно с заданным промежутком.
Также никогда не использовал BukkitRunnable, имхо, какая-то излишняя прослойка =)

Может быть я что-то делаю не так?

ql_Nik_lp · 19 сен 2016

Reality_SC сказал(а):
Также никогда не использовал BukkitRunnable, имхо, какая-то излишняя прослойка =)

Так он сейчас даже deprecated помечен.
А раньше вроде только от него шедулеры наследовать можно было.

Одна из немногих причин почему может понадобиться использовать Thread - задержка менее одного тика. Но на деле весьма странное занятие, да
Хотя я как-то шаманил так

Reality_SC · 19 сен 2016

ql_Nik_lp сказал(а):
Одна из немногих причин почему может понадобиться использовать Thread - задержка менее одного тика.

Мне кажется, если задержка меньше 1 тика, она вообще не нужна. syncronized или другие способы выручат не поломать данные.
Ну а параллельные потоки полезны для наоборот, ресурсо-ёмких операций, например общение с СУБД, запись/чтение тяжёлых файлов или просто громоздкие вычисления.

ql_Nik_lp · 19 сен 2016

Reality_SC сказал(а):
Мне кажется, если задержка меньше 1 тика, она вообще не нужна. syncronized или другие способы выручат не поломать данные.

Я это и имел ввиду)

Reality_SC сказал(а):
Ну а параллельные потоки полезны для наоборот, ресурсо-ёмких операций, например общение с СУБД, запись/чтение тяжёлых файлов или просто громоздкие вычисления.

Уже пару лет как обращаюсь к бд в асинхронных шедулерах по 1 на запрос, и отлично себя чувствую.
Конечно можно реализовать многопоточную очередь и работника который будет в ней копаться... Но тут все
зависит от того как часто производится запись в бд. В большинстве случаев я не считаю это необходимым.

В целом да, я просто повторил твое сообщение :oops:

Dereku · 19 сен 2016

Reality_SC сказал(а):
syncronized или другие способы выручат не поломать данные.

Мне кажется, что synchronized способен только вызвать зависание потока, если tps сервера меньше 18.

ql_Nik_lp · 19 сен 2016

Я обычно просто использую Concurrent коллекции для подобных целей.
Так же еще есть такая замечательная штука

Reality_SC · 19 сен 2016

Dereku сказал(а):
Мне кажется, что synchronized способен только вызвать зависание потока, если tps сервера меньше 18.

Главное, чтобы другие не делали в своём блоки syncronized кучу работы =) а для простого обмена информацией более чем годится.
Но нельзя и не согласиться с

ql_Nik_lp сказал(а):
Я обычно просто использую Concurrent коллекции для подобных целей.

— там миллионы всего на все случаи жизни.

Lisenochek · 19 сен 2016

То ли я немного глупенький, то ли ql_nik_lp плохо объяснил. Можно мне подробнее расписать весь принцип? А с кодом я попробую что-то сделать.

ql_Nik_lp · 19 сен 2016

Lisenochek сказал(а):
То ли я немного глупенький, то ли ql_nik_lp плохо объяснил. Можно мне подробнее расписать весь принцип? А с кодом я попробую что-то сделать.

Discord: M3lon#1817
Расскажу голосом

Lisenochek · 19 сен 2016

ql_Nik_lp сказал(а):
Discord: M3lon#1817
Расскажу голосом

Ну... Вроде бы я тебе отправил инвайт.

Bars · 19 сен 2016

Пф, блин... даже не озадачили.
Создаешь один щчедуллер, который срабатывает каждый тик...

Java:

int timer = 0; // Глобальная переменная

...

getServer().getScheduller().runTaskTimer(this, new Runnable() {
@Override
public void run() {
  if (timer % 20 == 0) { // 20 тиков / 20 = 1 секунда
    // Здесь код будет выполняться каждую секунду
  }

  if (timer % 1200 == 0) { // 1200 тиков / 20 = 60 секунд = 1 минута
    // Здесь код будет выполняться каждую минуту
  }

  if (timer % 240 == 0) { // 240 тиков / 20 = 12 секунд
    // Здесь код будет выполняться каждые 12 секунд
  }

  ++timer;
}
}, 1L, 1L);

Всё в одном! Юзаю сам и советую вам

Помогите Аналог шедулеров.. Много шедулеров

Активный участник

Старожил

Активный участник

Старожил

Активный участник

Старожил

Активный участник

Старожил

Активный участник

Старожил

Старожил

Старожил

Старожил

Старожил

Старожил

Старожил

Активный участник

Старожил

Активный участник

Старожил