同期プログラミングと非同期プログラミング:それらはどのように異なりますか?
特にプログラミングにまだ慣れていない場合は、いくつかのコーディング用語が威圧的であることに同意するでしょう。
一部の開発者にとって、「非同期」や「同期プログラミング」などの用語は、紛らわしいがよく使用されるコーディング用語に分類されます。では、これらの用語はどういう意味ですか?それらはどう違いますか?そして、それらはどのように機能しますか?これらすべての質問などに答えます。
同期プログラミングのしくみ
同期Webアプリは、リソースを単独で順次ロードするため、階層内の上位のリソースまたはコンポーネントがロードに失敗した場合、その下位のリソースは応答しません。
同期的に行う要求は、マルチスレッドプロトコルで動作します。
注:スレッドは、プログラミングで要求を処理する単一のエンドツーエンドのワーカーまたはチャネルです。
これらの各スレッドは、同期プログラミングで要求を個別に処理します。したがって、各スレッドには実行時間があり、次のイベントを実行する前に完全にロードされます。その結果、スレッドでイベントを実行すると、他のスレッドがロックされ、プロセス内のユーザーインターフェイス全体がブロックされます。

通常、同期プログラミングのみで実行されるWebアプリは、ロック内でリソースを依存的にロードします。常に、POSTおよびGETリクエストを含むすべての操作は、リクエストとレスポンスごとに新たにロードする必要があります。
したがって、同期呼び出しは、クライアントまたはブラウザが次の要求を実行する前に最初の要求から応答を取得することを保証します。これにより、不必要な遅延が発生し、ユーザーエクスペリエンスが低下する可能性があります。
たとえば、同期して実行されるWebサイトでフォームを送信しようとしているときに、必要なフィールドに入力してフォームを送信すると、クライアント(ブラウザー)はフォームフィールド全体をロックします。
そのため、送信中にフォームフィールドをさらに更新したり、Webアプリの他の部分をクリックしたりすることができなくなります。
node.jsのfsモジュールを使用してファイルのコンテンツを読み取る同期コードの例を次に示します。
var fs = require('fs');
const readData = fs.readFileSync('text.txt');
console.log(readData.toString());
setTimeout(()=>{
console.log('Hello world, I block other threads...')
}, 1000
);
上記のコードは、 readFileSyncメソッドを使用してテキストファイルのコンテンツを取得しますが、コールバック関数は使用しません。
非同期プログラミングのしくみ
非同期プログラミングでは、アプリは非ブロッキング入出力(I / O)プロトコルを使用して要求と応答を提供します。同期プログラミングとは異なり、非同期プログラムは階層的に操作を実行しません。したがって、プログラムは、別の要求で応答する前に、要求の実行を待機しません。
本質的には、リクエストが異なる機能にある場合でも、リクエストを同時に実行します。その結果、非同期プログラミングで開発されたアプリケーションは、コンテンツ全体を1回だけロードします。
1つのスレッドが、イベントループ内の複数の要求を処理します。したがって、一方の要求が失敗しても、もう一方には影響しません。

非同期読み込みは非ブロッキングであるため、この原則に基づいて動作するWebアプリは、最終的に単一ページのアプリケーションになる可能性があります。
たとえば、同期プログラミングとは異なり、フォームに入力して送信した後、関数は他のフィールドやユーザーインターフェイス全体をロックせずに非同期でフォームを送信します。したがって、送信の進行中に、他のフォームフィールドを更新し、Webアプリでさらにリクエストを行うことができます。
したがって、リクエストはすべて単一のループで実行されるため、リクエストを待つ必要はありません。そのため、同期アプリケーションとは異なり、非同期アプリはより優れたユーザーエクスペリエンスを提供し、同様に高速です。
node.jsで非同期コードがどのように表示されるかの例を次に示します。
var fs = require('fs');
fs.readFile('text.txt', function(err, data){
if(err){
console.log('Sorry, an error occured');
}
setTimeout(()=>{
console.log(data.toString())
}, 1000);
});
setTimeout(()=>{
console.log('Hello world, I don't block other threads...')
}, 500
);
以前の同期メソッドとは異なり、上記の非同期コードはコールバック関数を使用してエラーメッセージをカスタマイズします。
同期および非同期プログラミングの言語サポート
Python、C#、Java、PHPなどのほとんどのサーバー側言語はコードに依存して実行されるため、1行またはブロック全体が成功するかどうかは、その前の言語の成功に依存します。これは、デフォルトですべて同期していることを意味します。
これらのサーバー側言語のほとんどは、最近の進歩により非同期呼び出しをサポートするようになりましたが、デフォルトでは非同期呼び出しはありません。
注目すべきサーバーサイドJavaScriptフレームワークであるNode.jsは、非同期プログラミングをサポートするシングルスレッドランタイムの例です。非同期/待機タスクがC#でも可能になりました。
同期プログラミングと非同期プログラミングの長所と短所
ここでは非同期プログラミングが勝つと思うかもしれませんが、どちらの方法にも長所と短所があります。したがって、どちらを使用するかは、好みや目前の問題によって異なります。
ただし、どちらもさまざまな点で互いに優れています。これらのプログラミング方法のそれぞれの長所と短所を見てみましょう。
非同期プログラミングの長所
- すべてのスクリプトは一度に1つずつロードされます。これは、速度、応答性、およびユーザーエクスペリエンスの向上に相当します。
- ページの読み込み遅延を排除します。したがって、新しいリクエストの実行中に後続のページを更新する必要はありません。
- 他のリクエストがまだ実行されている場合でも、一度に複数の機能を使用できます。
- 非同期アプリは非常にスケーラブルであり、動作するために必要なリソースはほとんどありません。
- 1つのリクエストの応答が遅い場合でも、他のリクエストの応答時間には影響しません。
- スレッドの失敗は、他のスレッドのレンダリングを停止しません。
- 組み込みのコールバックを使用すると、エラーメッセージをカスタマイズできます。
非同期プログラミングの短所
- 多くのコールバックと再帰関数が必要であり、開発中に面倒になる可能性があります。
- コールバックが効果的に使用されていない場合、特にPOST要求を行うときに、要求が失敗したかどうかをユーザーが知る方法はありません。
- 最初のページレンダリングの遅延は、エクスペリエンスに影響を与える可能性があります。
- 非同期読み込みを使用するWebアプリは、GoogleやBingなどの検索エンジンではクロールが難しい場合があります。
- 一部のプログラミング言語では、非同期スクリプトを実装するのが難しい場合があります。
- コードが乱雑になり、デバッグが困難になる可能性があります。
同期プログラミングの長所
- コーディングのノウハウが少なくて済み、すべてのプログラミング言語でサポートされています。
- リクエストの失敗に対してカスタマイズされたコールバックがない場合でも、クライアント(ブラウザー)がデフォルトでそのようなエラーを処理するため、すぐにわかります。
- CPUタスクの実行に適しています。
- 検索エンジンは、同期Webページをクロールしやすいと感じています。
- 簡単なリクエストに最適です。
同期プログラミングの短所
- 読み込み時間が遅くなる可能性があります。
- 組み込みのコールバックメソッドはありません。
- スレッドがロックされると、他のスレッドもブロックされます。
- 一度に複数の操作を実行できないと、ユーザーエクスペリエンスが低下する可能性があります。
- リクエストが失敗すると、プログラム全体も応答しなくなります。
- リクエストが圧倒的になると、より多くのスレッドを処理するために膨大な量のリソースが必要になる場合があります。
同期プログラミングまたは非同期プログラミング:どちらが良いですか?
同期プログラミングは遅く、非同期スクリプトは高速で実行される可能性がありますが、あらゆるシナリオに適した方法を認識することが重要です。時には、彼らは一緒に働くことさえあります。
CRUD(作成、読み取り、更新、削除)などのバックエンド操作は、デフォルトで同期されています。ただし、CRUD操作を非同期で実行することもできます。バックエンドコードに接続するには、フロントエンドスクリプトを微調整するだけです。たとえば、データベースのデータを同期的にレンダリングできます。次に、非同期スクリプトを使用してユーザーに提示できます。
さらに、非同期プログラミングを使用して単純なフロントエンドアプリを構築したり、より少ないリソースを必要とするCPU操作を実行したりすることは理想的ではない場合があります。