Конечные автоматы вам нужны всякий раз, когда вам нужно освободить поток, прежде чем вы завершите свою операцию.
Поскольку веб-службы часто не имеют состояния, вы обычно не видите этого в веб-службах - вы реорганизуете свой URL, чтобы каждый URL соответствовал одному пути через код.
Полагаю, можно по-другому подумать о том, что каждый веб-сервер - это FSM, в котором информация о состоянии хранится в URL.
Вы часто видите это при обработке ввода. Вы должны освободить ваш поток до того, как ввод будет завершен, поэтому вы устанавливаете флаг, говорящий «ввод в процессе» или что-то в этом роде. Когда вы закончите, вы установите флаг «в ожидании ввода». Этот флаг - ваш государственный монитор.
Чаще всего FSM реализуется как оператор switch, который включает переменную. Каждый случай - это другое состояние. В конце дела вы можете установить состояние на новое значение. Вы наверняка где-то видели это.
Приятной особенностью FSM является то, что вы можете сделать состояние частью своих данных, а не своего кода. Представьте, что вам нужно заполнить 1000 пунктов в базе данных. Входящие данные будут адресованы одному из 1000 элементов, но у вас обычно недостаточно данных для завершения операции.
Без FSM у вас могут быть сотни потоков, ожидающих остальных данных, чтобы они могли завершить обработку и записать результаты в БД. С помощью FSM вы записываете состояние в БД, а затем выходите из своего потока. В следующий раз вы сможете проверить входящие данные, прочитать состояние из потока, и это должно дать вам достаточно информации, чтобы определить, какой код запустить.
Почти каждая операция FSM МОЖЕТ быть выполнена путем выделения ему потока, но, вероятно, не так (сложность увеличивается в зависимости от количества состояний, тогда как с помощью конечного автомата рост сложности становится более линейным). Кроме того, существуют некоторые проблемы концептуального проектирования - в некоторых случаях анализ вашего кода на уровне состояния гораздо проще, чем на уровне кода.