🐠 ✉️ 😺 非同期関数の順次呼び出しのスパゲッティ。理論と実践 👨🏿‍⚕️ 🙇🏾 ✍🏻

記事「非同期関数の順次呼び出し」の続き。

パート1.理論

従来のほとんどの非Webプログラミング言語は同期（ブロッキング）です。

特定の言語が同期か非同期かを判断するにはどうすればよいですか？たとえば、プログラムが一定時間完全に停止したときのスリープ機能の有無（遅延、一時停止などとも呼ばれます）。

ご存知のように、JavaScriptにはそのような機能はありません。たとえば setTimeoutですが、まったく異なることを行います。コマンドの実行を遅らせるかもしれませんが、これはsetTimeoutの後、プログラムが停止し、その中で何もできないという意味ではありません。

逆に、理論的には、 setTimeoutが呼び出された後、一部のリソースが解放され、遅延コールバック（キュー内の関数）がより高速に実行される場合があります。

同期/非同期とシングルスレッド/マルチスレッドを混同しないことをお勧めします。これらの概念は疎結合です。

JavaScriptで非同期を実装することは、別の概念への1つのアプローチにすぎません-マルチタスク、これには最も伝統的な解決策があります-マルチスレッド

マルチスレッドの利点：

考え方を変えたり、従来のブロッキング言語（C ++、Java、Python）から再訓練する必要はありません
マルチプロセッサコンピュータを使用していて、プログラムがスレッドを使用して記述されていて、それらが互いにブロックしない場合、つまり独立したデータで動作し、そのようなプロセッサ上のプログラムはわずかに速く動作します

マルチスレッドの欠点：

各スレッドにはデータを処理する場所が必要なので、このメモリが使用されておらずスレッドがスリープしている場合でも、各スレッドはRAMを使い果たします。

これは以前は大きな問題でしたが、現在メモリは安価ですが、単純だがマルチスレッドのJavaプログラムが2 GBのメモリを占有すると、どういうわけか不快になります。
2つのストリームが同じ希少なリソース（メモリ内のオブジェクト、ネットワーク接続など）を使用する場合、リソースのフローの競合（競合状態）が発生する可能性があります。「起こり得る」というのは、「起こる」と言った場合よりもさらに悪いことです。

スレッド間の競合に対抗するために、フラグ、セマフォなどが使用されます。これらには1つの目標があります。他のスレッドに乏しいリソースを待機させることです。ただし、スレッドAがスレッドBを待機し、BがAを待機している場合、デッドロックの問題が発生する可能性があります。

これらはマルチスレッドの2つの最大の欠点です。たとえば、Javaプログラマーを雇う際のインタビューでは、「 Thread.start（）はThread.run（）とどう違うのですか？ 」、「 How」デッドロックと戦う？ 」など Javaプログラマーは、スレッドの英雄的な作成に多大な時間を費やし、それからこれに関連する問題の同様に英雄的な克服に時間を費やしています。

おそらくご存知のように、従来のプロセッサの開発には一定の限界があり、ギガヘルツレースによる生産性の向上はもはや不可能です。この場合、マルチスレッド化により、たとえばビデオのエンコード時など、大量の多かれ少なかれ独立したデータの処理が大幅に増加します。

それにもかかわらず、プログラマー側のマルチスレッド化によるマルチタスクの印象は次のとおりです。 デッドロック 。」

Javascriptで、並列タスクを作成するには、次のように書くだけです。

setTimeout(function () { console.log('Async'); }, 0);

または

 button.addEventListener('click', function () { console.log('Async click'); }, false)

ただし、「並列タスク」は、10コアプロセッサ上でJavaScriptがより高速に動作することを意味するものではありません。 JavaScriptはスレッド中立であり、ECMA仕様はJavaScriptエンジンがマルチタスクを実装する方法を説明していません。私の知る限り、既存のJavaScript実装はすべて、「ユーザー空間のストリーム」などのマルチタスクオプションを使用します（プロセッサは単一プロセス内でタイマーを中断することでタスクを迅速かつ迅速に切り替えます）が、これは将来、核マルチスレッドがJavaScriptに表示されないことを保証するものではありません。

将来的には、結局のところ、ストリームはWebワーカーを介して少し奇妙な方法で強制的にJavaScriptに導入されましたが、これについては後半で説明します。

そのため、標準JavaScriptでは、無限のイベントループ（イベントループ）とノンブロッキングコールを介して、すべてが異なる方法で実行されます。このイベントループはメインの唯一のUIスレッドで実行され、コールバックキューにアクセスし、キューがクリアされるまで順番に選択して実行します。

trueフラグを指定してsetTimeout、onclick、およびXmlHttpRequestを呼び出すと、新しいコールバックがイベントキューに入れられます。コールバックをキューから選択して実行すると、実行中に別のコールバックなどをキューに入れることができます。

ロードに2時間もかからない高速JavaScriptを備えた高速なWebサイトが必要な場合は、できるだけ多くの操作を遅らせて、できるだけ早くメインスレッドにジャンプしてUIを解放します。イベントマネージャーは、いつ、何をキューから呼び出すかを判断します。アイテムは徐々にロードされます。

コールバックキューをスキャンするプロセスは中断せず、待機しません。データを徐々にロードしてもプログラム自体の最終速度は変わりませんが、要素が徐々に表示される非同期サイトは、訪問者によって高速であると認識されます。

JavaScriptは非同期操作に非常に適しており、まさにそのように設計されました。

残念ながら、構文には同期例外があります。これらは、すべてをブロックするfalseフラグ付きの alert 、 confirm 、 promtおよびxmlhttprequestコマンドです。

おそらく、記事の最後で説明する1つの例外を除き、これらのコマンドを使用しないことを強くお勧めします。

パフォーマンスの点では、非同期呼び出しは同期呼び出しよりも常に優れています。たとえば、 nginxを見てください。これは、主に非同期操作を実現する高性能のため、非常に人気があります。

残念なことに 、 node.jsはまだ抵抗できず、別の同期コマンド-requireを導入しました。このコマンドがnode.jsにある限り、パフォーマンスは常に不十分であると確信しているため、個人的には使用しません。

では、なぜ同期コマンドが非同期言語に導入されて、言語のイデオロギー全体が損なわれるのでしょうか？

まず、JavaScriptマシンはそれ自体では動作しませんが、ユーザーが座っているブラウザーではブロックコマンドがJavaScript言語ではなく、それを取り巻く環境（ブラウザー）に追加されましたが、これらの概念を論理的に分離することは困難です。

「ブラウザの反対側」に座っているプログラマーは、最も多様で、異なる言語から来ており、ほとんどの場合同期的です。非同期コードの記述ははるかに難しく、まったく異なる考え方が必要です。

そのため、「 非同期性をほとんど理解していないプログラマーの要求に応じて 」、イベントループを完全に停止する通常の悪質な同期関数を追加しました。

タスクを非同期的に完了する機会は常にありますが、非同期呼び出しを同期呼び出しに置き換えることで生活を簡素化する誘惑は大きすぎます。

非同期開発の複雑さは何ですか？

たとえば、遅かれ早かれ、JavaScriptプログラマーはこのような「バグ」に遭遇します（StackOverflowで最も一般的な質問の1つ）。

サーバーコード

 <?php #booklist.php header('Content-type: application/json'); echo json_encode(array(1, 2, 88)); ?>

クライアントコード

 var getBookList = function () { var boolListReturn; $.ajax({ url : 'bookList.php', dataType : 'json', success : function (data) { boolListReturn = data; } }); return boolListReturn; }; console.log(getBookListSorted()); // -   :)

もちろん、ここでの誤解は、ajaxリクエストがキューに入り、console.logがメインのUiスレッドに残っているという事実に起因しています。

ajaxが成功すると、成功コールバックをキューに入れますが、いつかは成功するかもしれません。もちろん、console.logは、関数が返された（未定義の）事実を含む過去のものです。

プログラムを少し変更する方が正確です。成功コールバック内でconsole.log呼び出しを渡すとしましょう。

 var getBookList = function (callback) { $.ajax({ url : 'bookList.php', dataType : 'json', success : function (data) { callback(data); } }); }; getBookList(function (bookList) { console.log(bookList); });

さらに現代的な方法は、コールバックを操作するための便利なインターフェイスに切り替えることです。たとえば、いわゆる「約束」（約束、遅延とも呼ばれます）-独自のコールバックキュー、現在の状態のフラグ、その他のグッズを保存する特別なオブジェクトです。

 var getBookList = function () { return $.ajax({ url : 'bookList.php', dataType : 'json', }).promise(); }; //     promise    done getBookList().done(function (bookList) { console.log(bookList); });

ただし、コールバックの負荷を増やすと、2つ以上の非同期コマンドを使用すると問題が発生するという2番目の問題が発生する可能性があります。

別のサービスbook.phpを使用して、リストIDから書籍の名前を見つける必要があると想像してください。

サーバー部分：

 <?php #book.php $id = $_REQUEST['id']; $response = array( "id" => $id ); switch ($id) { case '1': $response['title'] = "Bobcat 1"; break; case '2': $response['title'] = "Lion 2"; break; case '88': $response['title'] = "Tiger 88"; break; } header('Content-type: application/json'); echo json_encode($response); ?>

クライアントコードは次のようになります。

 var getBookList = function () { return $.ajax({ url : 'bookList.php', dataType : 'json', }).promise(); }; var getBook = function (id) { return $.ajax({ url : 'book.php?id='+id, }).promise(); }; getBookList().done(function (bookList) { $.each(bookList, function (index, bookId) { getBook(bookId).done(function (book) { console.log(book.title); }); }); });

この3階建てのコードは、すでにそれほどではありません。もちろん、ここで何が起こっているのかを把握することは可能ですが、大量のネストは実際には妨げとなり、バグが発生する可能性のある場所になります。

これがバグの1つです。 IDリストがソートされている場合、ソートが失われる可能性があります。たとえば、一部のリクエストが他のリクエストよりも遅い場合、またはユーザーがトレントダウンロードを並行して実行し始めた場合、リクエストの結果の発行速度は「スキップ」する場合があります。

phpでは、sleepコマンドでこれをエミュレートします。

...

ケース '2'：

睡眠（2）;

$ response ['title'] = "ライオン2";

休憩;

...

スクリプトは出力します

ボブキャット1

タイガー88

ライオン2

リストはアルファベット順にソートされていないため、問題はここに表示されます！..

リクエストの時間が異なる間、どのようにリストを整理できますか？

この問題は見かけほど単純ではなく、約束のオブジェクトでさえここではあまり役に立たず、この問題を自分で解決しようとすると、自分の肌で状況のドラマを感じるでしょう。

パート2.練習

JavaScriptライブラリのこの不完全なリストをご覧ください。

async.js、async、async-mini、atbar、begin、chainsaw、channels、Cinch、cloudd、deferred、それぞれ、EventProxy.js、fiberize、fibers、fibers-promise、asyncblock、first、flow-js、funk、futures、 promise、groupie、Ignite、jam、Jscex、JobManager、jsdeferred、LAEH2、miniqueue、$ N、nestableflow、node.flow、node-fnqueue、node-chain、node-continuables、node-cron、node-crontab、node-inflow 、node_memo、node-parallel、node-promise、narrow、neuron、noflo、observer、poolr、q、read-files、Rubberduck、SCION、seq、sexy、Signals、simple-schedule、Slide、soda.js、Step、stepc 、streamline.js、sync、QBox、zo.js、一時停止可能、ウォーターフォール

これらのバイクライブラリはすべて、「同期形式で非同期コードを書く」という1つの問題を解決することを約束します。つまり非同期コードを書くことは、同期的に書くのと同じくらい簡単です。

私はそれらのほとんどを試しましたが、実際には彼らは本当に助けにはなりません。標準のjQuery.Deferredと比較すると、大きな便利さに気付きませんでした。

しかし、それでも、オプションとは何かを考えてみましょう。

オプション1「同期コール」

ネストされたクエリの問題に対する明らかな解決策（リストを取得し、リストの要素を調べて、元のリストの順序を維持しながら各要素に対して別の要求を実行する）は、すべての呼び出しを同期させるために愚かです：

 var getBookList = function () { var strReturn; $.ajax({ url : '../bookList.php', dataType : 'json', success : function (html) { strReturn = html; }, async : false }); return strReturn; }; var getBook = function (id) { var strReturn; $.ajax({ url : '../book.php?id='+id, success : function (html) { strReturn = html; }, async : false }); return strReturn; }; var getBookTitles = function () { return $.map(getBookList(), function (val, i) { return getBook(val).title; }); }; var ul = $('<ul/>').appendTo($('body')); $.each(getBookTitles(), function (index, title) { $('<li>'+ title +'</li>').appendTo(ul); });

このソリューションは、「非常に高速でダーティな」シリーズのものです。なぜなら、リクエストはブラウザをブロックするだけでなく、次のリクエストが前のリクエストを待つため、それを長くするからです。

長所

エラーをキャッチしやすいシンプルなコード
テストが簡単

短所：

ブラウザをブロックします
結果の時間は、すべてのリクエストの時間の合計です

オプション2「リストに含まれるすべての約束の履行を待つ約束」

書籍のリスト自体は1つの約束（リストではなく）になりますが、その中には個々の約束のリストが含まれ、それに含まれるすべての約束が満たされた後にのみ、

結果は、同期データを含む配列として返されます

 var getBookTitles = function () { var listOfDeferreds = []; var listDeferred = $.Deferred(); getBookList().done(function (bookList) { $.each(bookList, function (i, val) { listOfDeferreds.push(getBook(val)); }); $.when.apply(null, listOfDeferreds).then(function () { listDeferred.resolve($.map(arguments, function (triple) { return triple[0].title; })); }); }); return listDeferred.promise(); }; getBookTitles().done(function (bookTitles) { $.each(bookTitles, function (index, title) { $('<li>'+ title +'</li>').appendTo('#ul'); }); });

getBookTitles関数コードは非常に重いです。主な問題は、それが間違っている、問題をキャッチするのが難しい、デバッグが難しいということです。

このオプションの利点：

ブラウザをブロックしません
結果の時間は、クエリの最長です。

短所：

複雑で欠陥のあるコード
テストが難しい

オプション3「uiでの結果の場所の予約」

この場合、IDリストを受け取って、それに含まれる要素を反復処理し、すぐにUIオブジェクトを作成します。

同じ繰り返しで、非同期データの2番目の部分を要求しますが、UIエレメントはクロージャーを通して表示され、コンテンツでそれを埋めます。

 getBookList().done(function (bookList) { $.each(bookList, function (index, id) { var li = $('<li>Loading...</li>'); li.appendTo('#ul'); getBook(id).done(function (book) { li.html(book.title); }); }); });

長所

ブラウザをブロックしません
結果は、個々のリクエストが終了するとすぐに表示されます。
リクエストは並行して行われます

短所：

中判コード
テストが難しい

オプション4「個別のWebworkerスレッドでの同期呼び出し」

記事を書いている過程で、ちょっと変わったオプションが出てきました-同期リクエストを実行しますが、WebWorkerとモジュールを介した別のスレッドで。この場合、ブラウザーはブロックされませんが、コードは簡素化されます。

これを行うには、ワーカー用のファイルを作成し、さらにnode.jsのrequireのような同期関数を使用します。

 // wwarpc.js var require = function () { // Only load the module if it is not already cached. var cache = {}; var gettext = function (url) { var xhr = new XMLHttpRequest(); xhr.open("GET", url, false); // sync xhr.send(null); if (xhr.status && xhr.status != 200) throw xhr.statusText; return xhr.responseText; }; return function (url) { if (!cache.hasOwnProperty(url)) { try { // Load the text of the module var modtext = gettext(url); // Wrap it in a function var f = new Function("require", "exports", "module", modtext); // Prepare function arguments var context = {}; // Invoke on empty obj var exports = cache[url] = {}; // API goes here var module = { id: url, uri: url }; // For Modules 1.1 f.call(context, require, exports, module); // Execute the module } catch (x) { throw Error("ERROR in require: Can't load module " + url + ": " + x); } } return cache[url]; } }(); onmessage = function(e){ if ( e.data.message !== "start" ) { return } var url = e.data.url; var funcname = e.data.funcname; var args = e.data.args; var module = require(url); postMessage(module[funcname].apply(null, args)); };

ワーカーを便利に起動するための補助機能は次のとおりです。

また、ワーカーとモジュールの両方をキャッシュして、呼び出しごとにサーバーからモジュールをロードしないようにします。

 //   ,     ,  <script src="http://ie-web-worker.googlecode.com/svn/trunk/worker.js"></script> /** * Web Worker Asynchroneous Remote Procedure Call */ var wwarpc = function () { var worker; var getWorker = function () { // for lazy load if (worker === undefined) { worker = new Worker("wwarpc.js"); } return worker; }; return function (url, funcname) { var args = Array.prototype.slice.call(arguments, 2); var d = $.Deferred(); var worker = getWorker(); worker.onmessage = function (e) { d.resolve(e.data); }; worker.postMessage({ message : "start", url : url, funcname : funcname, args : args }); return d.promise(); }; }();

興味深いことに、モジュールはnode.jsのようになります。

 //modules/Books.js exports.getBookList = function () { var the_object = {}; var http_request = new XMLHttpRequest(); http_request.open( "GET", 'bookList.php', false ); http_request.send(null); if ( http_request.readyState == 4 && http_request.status == 200 ) { the_object = JSON.parse( http_request.responseText ); } return the_object; }; exports.getBook = function (id) { var the_object = {}; var http_request = new XMLHttpRequest(); http_request.open( "GET", 'book.php?id='+id, false ); http_request.send(null); if ( http_request.readyState == 4 && http_request.status == 200 ) { the_object = JSON.parse( http_request.responseText ); } return the_object; }; exports.getBookTitles = function () { var Books = exports; return Array.prototype.map.call(Books.getBookList(), function (val, i) { return Books.getBook(val).title; }); };

同時に、モジュールの同じコードは、同期（ユニットテストによるテスト中）と非同期（実稼働中）の両方で呼び出すことができます。

これにより、メインコードは3つではなく2階建てになり、よりシンプルになります。

 wwarpc('modules/Books.js', 'getBookTitles').done(function (bookTitles) { $.each(bookTitles, function (index, title) { $('<li>'+ title +'</li>').appendTo('#ul'); }); });

イデオロギーでは、すべての操作がワーカーで実行されますが、ワーカーは非同期で呼び出されるため、ネストは常に最小限になります。

利点：

新しいブラウザをブロックしません
シンプルで理解しやすいコード
テストが簡単（同期モードでテストでき、非同期で呼び出すことができます）

短所：

IEおよびワーカーをサポートしていない古いブラウザーをブロックします
結果の時間は、すべてのリクエストの時間の合計です

結論：

オプション3「uiで結果の場所を予約する」が最速のオプションですが、やや複雑なコード
コードの可読性とテスト容易性がIEユーザーの快適さよりも重要である場合、オプション4「別のWebworkerスレッドでの同期呼び出し」が適切な選択になる可能性があります。
オプション2は厳密に回避する必要があります（「リストにあるすべての約束の履行を待つ約束」）
同期呼び出しを使用することは正当化できません
IEは死ななければなりません！

この記事は、次の資料の印象の下に書かれました。

非同期関数の順次呼び出しのスパゲッティ。 理論と実践