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

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

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

 

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

 

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

 

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

 

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

 

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

 

Буду пробовать...[DOUBLEPOST=1474188575,1474183683][/DOUBLEPOST]

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

 

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

 

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

 

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

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

 

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

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

 

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

 

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

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

ну а почемубы не сделать задержку 20 тиков? Ведь всёравно измеряем в целых числах, а не в 2.5 секунд и тд.