Последний год я работал над Java и flex. При написании гибкого кода большинство частей моего кода выбрасывались из-за его асинхронности. Это заставило меня задуматься о реальных преимуществах и недостатках синхронных исполняемых языков по сравнению с асинхронными.
В каких областях они сильнее по сравнению с другими и в каких областях они падают?
Я провел большую часть прошлого года за программированием в Silverlight, что означает, что я потратил много времени на обдумывание (и борьбу с) тех же проблем, которые вы описываете.
Короче говоря, как указывали другие люди, реальная сила асинхронной модели заключается в ее способности создавать надежные системы, которые хорошо взаимодействуют с реальным миром. Никто не мог бы реально использовать приложение Silverlight (или Flash), если поток пользовательского интерфейса останавливался каждый раз, когда для возврата вызова веб-службы требовалось несколько секунд.
Самым большим недостатком является то, что полученный код сложен и его трудно устранять. Такие вещи, как обработка ошибок, — это PITA, но самое раздражающее, с чем мне приходилось сталкиваться, — это координировать ответы от нескольких асинхронных вызовов. Если, скажем, вам нужна информация от звонка А перед выполнением звонка Б, и вам нужна информация от звонка Б до выполнения звонка С (и т. д.), результирующий код выглядит очень неприятно и восприимчив к всевозможным странным побочным эффектам. . Существуют методы, позволяющие заставить все это работать и даже достаточно чисто, но если вы пришли из синхронного мира (как и я), это требует значительного обучения. (И не помогает то, что Microsoft продвигает события как способ работы с вызовами WCF, когда обратные вызовы, на мой взгляд, намного чище и менее подвержены странным побочным эффектам, о которых я говорил.)
(И да, другие люди правы, говоря, что асинхронным является не столько язык, сколько конкретные фреймворки требуют построения вашего кода асинхронным образом, но я понимаю, что вы имеете в виду.)
Обновление 2014.09.23 -
Я проделал гораздо больше работы с различными асинхронными фреймворками с тех пор, как написал ответ выше (как, вероятно, и все остальные, кто занимался веб-кодированием), и подумал, что добавлю несколько дополнительных случайных заметок:
Если вы используете такие языки, как C# или F#, которые имеют первоклассную асинхронную поддержку, многое становится намного проще, по крайней мере, когда вы обдумываете странные шаблоны async/await. Возможность легко зацикливаться на асинхронных вызовах и обернуть все это простым try/catch — это потрясающе, если вам когда-либо приходилось делать это по-старому.
Если вы не используете язык с первоклассной поддержкой асинхронности, начните использовать любую поддержку promise, future или task, которую предоставляет язык (например, $.Deferred() в JQuery или $q.defer() в Angular. Они намного чище и обеспечивают лучшую структуру, чем то, что вы обычно получаете с обратными вызовами.
Асинхронный код имеет решающее значение для написания масштабируемых серверных систем. Одна из самых больших проблем с хорошим масштабированием типичного веб-сервера заключается в том, что у него начинают заканчиваться потоки, по крайней мере, если он выделяет поток для достижения входящего запроса. Если этот поток останавливается из-за ожидания завершения продолжительного синхронного вызова, он совершенно не может помочь с чем-либо еще. Гораздо лучше сделать код вашего веб-сервера асинхронным, чтобы, когда вы ожидаете возврата вызова БД, этот поток мог обслуживать полдюжины других запросов, пока БД работает и делает все, что делает БД. На данный момент для хорошо масштабируемых систем асинхронность — единственная игра в городе. (Просто спросите любого поклонника Node.)
(Оставляя в стороне обсуждение уровня семантики, т.е. «синхронный/асинхронный язык»)
«Структура», построенная на «языке» (каким бы он ни был), должна быть в состоянии обрабатывать такие случаи (синхронный/асинхронный поток программы), чтобы быть полезной (читай: $ мудрой).
Асинхронные идиомы подходят для любого масштаба.
В больших масштабах асинхронные методы помогают создавать надежные системы, поскольку реальный мир так или иначе асинхронен по своей природе. Другими словами, нужно мыслить «асинхронно», чтобы справляться с реальными жизненными ситуациями, такими как неудачи, потери, задержки и т. д.
Даже в меньшем масштабе (например, приложение с графическим интерфейсом) события (такие как «щелчки мыши») имеют тенденцию быть «асинхронными». Конечно, в какой-то момент они «сериализованы» (чтобы их можно было обработать приложением, работающим с некоторым программным обеспечением), но это не меняет того факта, что события (вероятно) происходили «асинхронно» по отношению к потоку рассматриваемой программы. .
Я думаю дело не в языке, а во фреймворке.
Контр-пример:
При написании приложений «Классический Mac» (MacOS 9 и более ранние версии) на C («синхронный» язык, если он когда-либо существовал), у вас нет вытесняющей многопоточности, поэтому все потенциально блокирующие системные вызовы имеют асинхронный аналог, где вы заполняете блок данных с параметрами, включая функцию обратного вызова. Затем вы выполняете системный вызов (который будет немедленно возвращен), и ваш обратный вызов будет вызываться асинхронно (на так называемом «уровне прерывания»). Нередко обратный вызов выполнял другой асинхронный системный вызов, создавая длинный фоновый поток, который выполнялся асинхронно с основным.
