Folia (By PaperMC) [1.21.4-DEV-dev/hard-fork@3af04d9]

О Folia​

Folia группирует близлежащие загруженные фрагменты, образуя "независимую область".
Подробнее о мультипоточных регионах в данном ПО - Ссылка на PaperMC
Каждый независимый регион имеет свой собственный цикл тиков, который помечается с
обычной скоростью тикирования Minecraft (20TPS). Циклы tick выполняются
в пуле потоков параллельно. Основного потока больше нет,
так как каждая область фактически имеет свой собственный "основной поток", который выполняет
весь цикл тика.

Для сервера с большим количеством распределенных игроков Folia создаст множество
распределенных регионов и будет отмечать их все параллельно на странице настраиваемого размера
пул потоков. Таким образом, Folia должна хорошо масштабироваться для подобных серверов.

Folia также является его собственным проектом, в обозримом будущем он не будет объединен с Paper.

Более подробный, но абстрактный обзор: Обзор проекта.

ЧАСТО задаваемые вопросы​

Какие типы серверов могут извлечь выгоду из Folia?​

Типы серверов, которые естественным образом распределяют игроков,
такие как skyblock или SMP, получат наибольшую выгоду от Folia. На сервере
также должно быть значительное количество игроков.

На каком оборудовании Folia будет работать лучше всего?​

В идеале, по крайней мере, 16 ядер (не потоков). (Дополнение от автора данного ресурса - можно настроить в конфиге Paper)

Как наилучшим образом настроить Folia?​

Во-первых, рекомендуется предварительно сгенерировать мир, чтобы значительно сократить количество требуемых системных рабочих потоков.

Ниже приведена очень приблизительная оценка, основанная на тестировании, проведенном до выхода Folia на тестовом сервере, который мы запустили, на котором было ~ 330 игроков на пике. Таким образом, это не точно и потребует дальнейшей настройки - просто примите это за отправную точку.

Следует принимать во внимание общее количество доступных ядер на компьютере.
Конфигурация:

• netty IO : ~4 на 200-300 игроков
• потоки ввода-вывода chunk system: ~3 на 200-300 игроков
• работники системы блоков, если они предварительно сгенерированы, ~2 на 200-300 игроков
• Нет лучшего предположения для воркеров системы чанков, если они не были предварительно сгенерированы, так как на тестовом сервере, который мы запустили, мы дали 16 потоков, но генерация чанков все еще была медленной при ~ 300 игроках.
• Настройки GC: ???? Но настройки GC выделяют параллельные потоки, и вам нужно

точно знать, сколько их. Обычно это делается с помощью флага -XX:ConcGCThreads=n. Не
путайте этот флаг с -XX:ParallelGCThreads=n, поскольку параллельные потоки GC выполняются только тогда, когда
приложение приостановлено GC и как таковое не должно приниматься во внимание.

После всего этого распределения оставшиеся ядра в системе до выделения 80% (общее количество выделенных потоков < 80% доступных процессоров) могут быть распределены между tickthreads (в глобальной конфигурации, threaded-regions.нити).

Причина, по которой вы не должны выделять более 80% ядер, связана с тем фактом, что плагины или даже сервер могут использовать дополнительные потоки, которые вы не можете настроить или даже предсказать.

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

[ < ! > ВАЖНО < ! > ] - Совместимость с плагинами​

Основного потока больше нет. Я ожидаю, что для работы в Folia каждому существующему плагину потребуется определенный уровень модификации. Кроме того, многопоточность любого рода вводит возможные условия гонки в данных, хранящихся в плагине, - таким образом, обязательно должны быть внесены изменения.

Итак, ваши ожидания относительно совместимости равны 0.

Планы API​

В настоящее время существует множество API, которые полагаются на основной поток. Я ожидаю, что практически нулевые плагины, совместимые с Paper, будут совместимы с Folia. Однако есть планы добавить API, который
позволил бы плагинам Folia быть совместимыми с Paper.

Например, планировщик Bukkit. Планировщик Bukkit по своей сути полагается на один основной поток. RegionScheduler Фолии и Folia's EntityScheduler позволяет планировать задачи до "следующего тика" любого
региона, "владеющего" местоположением или сущностью. Они могли бы быть реализованы на обычной бумаге, за исключением того, что они привязаны к основному потоку - в обоих случаях, выполнение задачи будет происходить в потоке, которому "принадлежит" местоположение или объект. Эта концепция применима в целом, поскольку текущую статью (однопоточную) можно рассматривать как одну гигантскую "область", которая охватывает все фрагменты во всех мирах.

Пока не решено, добавлять ли этот API непосредственно в саму Paper или в Paperlib.

Новые правила​

Во-первых, Folia ломает многие плагины. Чтобы помочь пользователям определить, какие плагины работают, будут загружены только те плагины, которые были явно отмечены автором(ами) для работы с Folia. Разместив "поддерживается folia: true" в plugin.yml плагина, авторы плагинов могут пометить свой плагин как совместимый с регионизированной многопоточностью.

Другим важным правилом является то, что регионы помечаются в parallel, а не concurrently. Они не обмениваются данными, они не ожидают совместного использования данных, а совместное использование данных приведет к повреждению данных.

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

Это означает, что плагины, совместимые с Folia, должны использовать преимущества API, подобный RegionScheduler и EntityScheduler для обеспечения их код выполняется в правильном контексте потока.

В общем, можно с уверенностью предположить, что регион владеет данными блока приблизительно в 8 блоках от источника события (т.е. игрок нарушает блок, вероятно, может получить доступ к 8 блокам вокруг этого блока). Но
это не гарантировано - плагины должны использовать преимущества предстоящего API проверки потоков, чтобы обеспечить правильное поведение.

Единственная гарантия потокобезопасности исходит из того факта, что один регион владеет данными в определенных блоках - и если этот регион помечен, то у него есть полный доступ к этим данным. Эти данные являются в частности, данные entity / chunk / poi и совершенно не связаны с ** КАКИМИ-либо ** данными плагина.

Обычные правила многопоточности применяются к данным, которые плагины хранят / получают доступ
к своим собственным данным или данным другого плагина - события / команды / и т.д. вызываются в parallel, потому что регионы помечены в parallel (мы НЕ МОЖЕМ вызывайте их синхронно, так как это приводит к возникновению взаимоблокировок и может снизить производительность). Простых путей выхода из этого нет,
это зависит исключительно от того, к каким данным осуществляется доступ. Иногда достаточно параллельной коллекции (например, ConcurrentHashMap), и часто небрежно используемая параллельная коллекция приведет только к проблемам с потоковой обработкой, которые затем станут практически невозможными для отладки.