JavaWeb - 基本

Java Web開発の基本的な内容:

• サーブレット: いくつかの制限された Java クラスが追加されているため、サーブレットの開発は複雑ではありません。その後、サーブレットを Web サーバーにデプロイし (Tomcat の老人はまだ元気です!)、あとは顧客のリクエストを待つだけです。

サーブレットの 3 層展開図

 

• ジャワビーン
• jsp

MVC (モデル、ビュー、コントローラー) 構造を使用してサーブレット、Javabean、JSP を組み合わせた標準 Javaweb 構造

 

MVC 関数図

         

1. 基本的な知識:

• Java Web はスレッド単位でリクエストを管理するため、処理能力が強化され、占有されるリソースが少なくなります。
• CGI はリクエストをプロセス単位で管理し、サーブレットは同じ数のリクエストを解決するが、占有するシステム リソースは少なくなります
• Java Web のコアコンポーネントはサーブレットです

CGIリソース使用量グラフ

 

Java Webのサーブレットリソースマップ

 

1. HTTP プロトコル (Hypertext Transfer Protocol):主流の B/S アーキテクチャで適用される通信プロトコル

• ステートレス: サーバーはクライアントから送信された各リクエストを記録せず、サーバーがクライアントに応答すると、通信プロセスを終了します。クライアントの次のリクエストは新しい接続であり、前の通信とは何の関係もありません。
• シンプルかつ柔軟: HTTP はリクエスト (リクエスト) とレスポンス (応答) モデルに基づいています。
• クライアントとサーバーのサポート: 主流の B/S アーキテクチャ通信と C/S アーキテクチャ通信をサポート
  • C/S アーキテクチャには、TCP/IP、UDP、HTTP などのオプションのプロトコルが多数ありますが、B/S アーキテクチャは通常、HTTP プロトコルのみをサポートします。

2. サーバー:通常、ハードウェア部分とソフトウェア部分で構成され、ユーザーにさまざまなサービスを提供します。

• ハードウェア: 対応する CPU、メモリ、ディスクなどを含む。
• ソフトウェア: オペレーティング システム、オペレーティング環境、サーバー ソフトウェア、データベースなどを含みます。

1)ウェブサーバー:

• Web サーバーはサーバー プログラムの実行を提供する環境であり、それ自体がソフトウェアです
  • 例: 作成した HTML ファイルを Web サーバーに置くと、外部の世界がブラウザを通じて HTML ページにアクセスできるようになります。
• 一般的な Web サーバーには、Apache、Tomcat、Jetty、Nginx などが含まれます。
  • Tomcat や Jetty などの Web サーバーは、正確にはサーブレット コンテナです。

3. JavaWeb プロジェクトの構造! ！！

プロジェクトのルート ディレクトリ (例: myweb、ch01)			通常は静的リソース ファイル (html など) を保存します。
	WEB-INF		このディレクトリは現在のプロジェクトのプライベート フォルダであり、プロジェクトへの内部アクセスのみに提供でき、クライアントからはアクセスできません。通常、Java ソース コード、コンパイルされたバイトコード ファイル、およびサーブレット ファイルはこのディレクトリに保存されます。コア構成ファイル web.xml
		送信元	Javaソースコードが保存されているディレクトリ
		クラス	コンパイルされたバイトコード ファイルを保存する
		ライブラリ	lib ディレクトリには、現在のプロジェクトに必要な jar ファイルが保存されます。
		JSP	JSP動的ページを保存するために使用されます
		web.xml	プロジェクトの設定ファイルは、サーブレットのリクエストマッピング、フィルター、リスナーなどの情報を設定するために使用されます。各 Web プロジェクトは web.xml 構成ファイルに対応します
	メタINF		アプリケーション、拡張機能、クラスローディング サービスなどを構成する

2、サーブレットと JSP の比較

1. サーブレットと JSP の違い:        

• サーブレットは、Java コードのHttpServletResponse オブジェクトを通じて HTML コンテンツを動的に出力できます
• JSP は、静的な HTML コンテンツに Java コードを埋め込み、Java コードが動的に実行されて HTML コンテンツを生成します。

• JSP はコンパイル後にサーブレットになります (JSP の本質はサーブレットであり、JVM は Java クラスのみを認識できますが、JSP コードは認識できません。Web コンテナは JSP コードを JVM が認識できる Java クラスにコンパイルします)。

• jsp はページの表示に優れ、サーブレットはロジック制御に優れています。

• サーブレットには組み込みオブジェクトはなく、組み込みオブジェクトは HttpServletRequest オブジェクト、HttpServletResponse オブジェクト、および HttpServlet オブジェクトを通じて取得する必要があります。
• Jspはサーブレットを簡略化したものです。Jspを使用することで、プログラマがクライアントに出力する必要のある内容だけを完成させることができます。Jsp内のJavaスクリプトをクラスに埋め込む方法は、Jspコンテナによって完成されます。
• サーブレットは完全な Java クラスであり、このクラスの Service メソッドはクライアントへの応答を生成するために使用されます。
• 静的 HTML タグの場合、サーブレットはページ出力ストリームを使用して行ごとに出力する必要があります。

2. サーブレットと JSP のそれぞれの特徴:

• サーブレットはビジネスロジックコードをうまく整理できますが、Javaソースファイルでは文字列を繋ぎ合わせて動的HTMLコンテンツを生成するため、コードのメンテナンスが難しくなり、可読性が低下しやすくなります。
• JSP はHTML コンテンツを生成する際のサーブレットの欠点を回避しますが、HTML に多くの複雑なビジネス ロジックが混在します。

3. MVC モードはサーブレットと JSP を使用します。

• サーブレットはビジネス ロジック部分のみを担当し、HTML コードを生成しません。
• JSP には多くのビジネス コードが詰め込まれないため、コードの可読性と保守性が大幅に向上します。

        MVC パターン (モデル-ビュー-コントローラー):ソフトウェア エンジニアリングにおけるソフトウェア アーキテクチャ パターン。モデル (Model)、ビュー (View)、およびコントローラー (Controller) の 3 つの基本部分に分かれています。

• コントローラー (サーブレット) - リクエストの転送とリクエストの処理を担当します。
• ビュー (JSP) - インターフェイスの表示を担当します。
• モデル - ビジネス関数の作成 (アルゴリズム実装など)、データベース設計、データ アクセス操作の実装

•  Web ブラウザは HTTP リクエストをサーバーに送信し、そのリクエストはコントローラ (サーブレット) によって取得および処理されます (パラメータの解析、リクエストの転送など)。
• コントローラー (サーブレット) がコア ビジネス ロジック (モデル部分) を呼び出し、結果を取得します。
• Controller(Servlet)は論理的な処理結果をView(JSP)に渡し、HTMLコンテンツを動的に出力する
• 動的に生成された HTML コンテンツがブラウザに返されて表示されます。

3. サーブレット

• Java サーブレットは、Web サーバーまたはアプリケーション サーバー上で実行されるプログラムです。
• Web ブラウザまたは他の HTTP クライアントからのリクエストと、HTTP サーバー上のデータベースまたはアプリケーションの間の仲介として機能します。
• サーブレットを使用して Web フォームからユーザー入力を収集し、データベースまたはその他のソースからレコードをレンダリングし、Web ページを動的に作成します

1. サーブレットの利点 (CGI と比較):

• パフォーマンスが大幅に向上 (リクエスト数は同じ、システム リソースの使用量は減少)
• サーブレットは Web サーバーのアドレス空間内で実行されるため、各クライアント要求を処理するための個別のプロセスが不要になります。
• サーブレットは Java で記述されているため、プラットフォームに依存しません。
• サーバー上の Java セキュリティ マネージャーは、サーバー コンピュータ上のリソースを保護するために一連の制限を適用します。したがって、サーブレットは信頼されます
• Java クラス ライブラリの全機能をサーブレットで利用できます。ソケットおよび RMI メカニズムを介してアプレット、データベース、またはその他のソフトウェアと対話できます。

2. サーブレットのライフサイクル

サーブレットのライフサイクルは、作成から破棄までのプロセス全体として定義できます。サーブレットが実行するプロセスは次のとおりです。

• サーブレットは init() メソッドを呼び出して初期化されます。
  • init メソッドは、アプレットの init メソッドと同様に、1 回限りの初期化のために 1 回だけ呼び出されるように設計されています。
  • これはサーブレットが初めて作成されるときに呼び出され、ユーザーが要求するたびに呼び出されるわけではありません。
  • サーブレットは、ユーザーがそのサーブレットに対応する URL を初めて呼び出したときに作成されますが、サーバーの初回起動時にサーブレットがロードされるように指定することもできます。
• サーブレットは、service() メソッドを呼び出してクライアントのリクエストを処理します。
  • service() メソッドは、実際のタスクを実行するメインのメソッドです。
  • サーブレット コンテナ (Web サーバー) は、service() メソッドを呼び出してクライアント (ブラウザ) からの要求を処理し、フォーマットされた応答をクライアントに書き込みます。
  • サーバーがサーブレット リクエストを受信するたびに、サーバーは新しいスレッドを生成してサービスを呼び出します。service () メソッドは HTTP リクエスト タイプ (GET、POST、PUT、DELETE など) を確認し、doGet、doPost、 doPut、doDelete、その他のメソッド
• サーブレットは destroy() メソッドを呼び出すことによって終了 (終了) します。
  • destroy() メソッドは、サーブレットのライフサイクルの最後に 1 回だけ呼び出されます。
  • destroy() メソッドを使用すると、サーブレットはデータベース接続を閉じ、バックグラウンド スレッドを停止し、Cookie リストを書き込んだりカウンターをディスクにヒットしたり、その他の同様のクリーンアップ アクティビティを実行したりできます。
  • destroy() メソッドを呼び出した後、サーブレット オブジェクトはガベージ コレクションの対象としてマークされます。
• 最後に、サーブレットは JVM のガベージ コレクターによってガベージ コレクションされます。

例：

最初のリクエスト:

 

 リクエストを続けます:

3. サーブレット関連の面接の質問

1) 異なるユーザーが同じ業務 (登録など) のリクエストを同時に送信します。この時点でコンテナ内にサーブレット インスタンスがいくつ生成されますか? (サーブレットの単一インスタンスのマルチスレッドを理解するにはどうすればよいですか?)! ！！

• サーブレット インスタンスは 1 つだけです。サーブレットはメモリにロードされ、最初にアクセスされたときにインスタンス化されます。
• 同じビジネス リクエストはサーブレット インスタンスを共有します。通常、異なるビジネス リクエストは異なるサーブレットに対応します。

• サーブレット/JSP はデフォルトでマルチスレッド モードで実行されるため、コードを記述する際にはマルチスレッドの安全性を十分に考慮する必要があります。

2) JSP におけるマルチスレッドの問題

• クライアントが初めて JSP ファイルを要求すると、サーバーは JSP を CLASS ファイルにコンパイルし、このクラスのインスタンスを作成して、クライアントからの要求を処理するスレッドを作成します。
• 複数のクライアントが同時に JSP ファイルを要求すると、サーバーは複数のスレッドを作成します。各クライアント要求はスレッドに対応します。マルチスレッド方式で実行すると、システムのリソース要件が大幅に削減され、システムの同時実行性と応答時間が向上します。

3) JSPで使用できる変数の説明

• インスタンス変数: インスタンス変数はヒープ内に割り当てられ、インスタンスに属するすべてのスレッドによって共有されるため、スレッドセーフではありません。
• JSP システムによって提供される 8 つのクラス変数:
  • JSPで使用されるOUT、REQUEST、RESPONSE、SESSION、CONFIG、PAGE、PAGECONXTはスレッドセーフです（各スレッドに対応するリクエストオブジェクトとレスポンスオブジェクトが異なるため、共有の問題は発生しません）
  • APPLICATION はシステム全体で使用されるため、スレッドセーフではありません
• ローカル変数: 各スレッドには独自のスタック領域があるため、ローカル変数はスタック上に割り当てられ、スレッドセーフになります。
• 静的クラス: 静的クラスはインスタンス化せずに直接使用できますが、スレッドセーフではありません。
• 外部リソース: プログラム内では、同じリソースを同時に操作する複数のスレッドまたはプロセスが存在する場合があります (例: 複数のスレッドまたはプロセスが同時にファイルに書き込む)。このとき、同期の問題にも注意してください。

4)サーブレットの単一インスタンスのマルチスレッド メカニズム:

• サーブレットはマルチスレッドを使用して、同時アクセスに対する複数のリクエストを処理します。
• サーブレットはリクエストを処理するためにスレッド プールに依存します。スレッド プールは実際にはワーカー スレッドのコレクションです。サーブレットはディスパッチャ スレッドを使用してワーカー スレッドを管理します
• コンテナがサーブレット リクエストを受信すると、スケジューリング スレッドがスレッド プールからワーカー スレッドを選択し、リクエストをワーカー スレッドに渡し、スレッドがサーブレットのサービス メソッドを実行します。
• このスレッドの実行中、コンテナは別のリクエストを受信し、スケジューリング スレッドも新しいリクエストを処理するためにスレッド プールから別のワーカー スレッドを選択します。コンテナはリクエストが同じサーブレットにアクセスしているかどうかを気にしません。
• コンテナが同じサーブレットに対する複数のリクエストを同時に受信すると、このサーブレットの service() メソッドが複数のスレッドで同時に実行されます。
• サーブレット コンテナは、デフォルトで単一インスタンスのマルチスレッドを使用してリクエストを処理します。これにより、サーブレット インスタンス生成のオーバーヘッドが削減され、リクエストへの応答時間が改善されます。Tomcat の場合、サーバーの要素を通じてスレッド プールのスレッド数を設定できます。 .xml

5)スレッドセーフなサーブレットを開発する方法

• SingleThreadModel インターフェイスを実装する
  • このインターフェースは、システムが同じサーブレットへの呼び出しを処理する方法を指定します。
  • サーブレットがこのインターフェイスで指定されている場合、このサーブレットのサービス メソッドでは 2 つのスレッドが同時に実行されることはなく、もちろんスレッドの安全性の問題は発生しません。このメソッドでは、前の Concurrent Test クラスのクラス ヘッダー定義を次のように変更するだけで済みます。

Public class Concurrent Test extends HttpServlet implements SingleThreadModel { 
………… 
}  

6)共有データに対する操作を同期する

• synchronized キーワードを使用して、保護されたセクションに一度に 1 つのスレッドだけがアクセスできるようにします。
• インスタンス変数の使用を避ける
  • この例のスレッド セーフの問題はインスタンス変数が原因であり、サーブレット内のメソッドでインスタンス変数が使用されていない限り、サーブレットはスレッド セーフです。

7) Struts1 アクションと Struts2 アクションの区別

• Struts2 アクションはプロトタイプであり、単一のインスタンスではありません。リクエストごとに、処理用にアクションのインスタンスが生成されます。
  • Struts2 Action オブジェクトはリクエストごとに 1 つのインスタンスを生成するため、スレッド セーフティの問題はありません(実際、サーブレット コンテナはリクエストごとに多くの破棄可能なオブジェクトを生成し、パフォーマンスやガベージ コレクションの問題は引き起こしません)。
• Struts1 Actionはシングルインスタンス、mvcのコントローラーもシングルインスタンス
  • したがって、Struts1 アクションと MVC コントローラーの開発は、すべてのリクエストを処理するアクションのインスタンスが 1 つだけであるため、スレッド セーフである必要があります。シングルトン戦略により、Struts1 アクションが実行できる内容が制限され、開発中に特別な注意を払う必要があります。
  • Struts1 アクション リソースはスレッドセーフであるか、同期されている必要があります
• Struts1 アクション、Spring の Ioc コンテナによって管理される Bean はデフォルトで単一インスタンスです
• Spring が Struts2 アクションを管理する場合、Bean はデフォルトで単一インスタンスであり、構成パラメーター (scope="prototype) を通じてプロトタイプとして設定できます。

4、JDBCデータベース接続プール

1. 接続プールを使用する理由:

データベースベースの Web プログラムを開発する場合、従来のモデルは基本的に次の手順に従います。

• メインプログラム(サーブレット、Beanなど)でデータベース接続を確立します。
• SQL操作を実行する 
• データベースから切断する

このモデルの問題点:

• 通常の JDBC データベース接続は DriverManager を使用して取得されます。データベースへの接続が確立されるたびに、接続がメモリにロードされ、ユーザー名とパスワードが検証される必要があります (0.05 秒から 1 秒かかります)。接続が必要です。データベースに接続を要求するだけで、実行が完了したら切断します。このようなアプローチは、多くのリソースと時間を消費します。データベース接続リソースは十分に再利用されません。数百人、さらには数千人が同時にオンラインになっている場合、データベース接続操作が頻繁に行われるとシステム リソースが大量に消費され、サーバーがクラッシュすることもあります。
• 各データベース接続は、使用後に切断する必要があります。そうしないと、プログラムが異常で閉じられなかった場合、データベース システムでメモリ リークが発生し、最終的にはデータベースが再起動されます。
• このような開発では、作成される接続オブジェクトの数を制御できず、システム リソースが考慮されずに割り当てられるため、接続が多すぎるとメモリ リークやサーバーのクラッシュが発生する可能性もあります。

接続プールは基本的に、作成されたスレッド、http 接続、データベース接続、netty 接続などを保存するコンテナを構築することです。

2. 接続プールの技術コア:

• 接続またはリソースの再利用が作成されました

3. 接続プールを使用する利点:

• 接続の再利用: データベース接続プールと一連の接続使用管理戦略を確立することにより、データベース接続を効率的かつ安全に再利用でき、データベース接続の頻繁な確立と終了によるオーバーヘッドを回避できます。
• 共有リソースには、リソース プールというよく知られた設計パターンがあります。このモードは、リソースの頻繁な割り当てと解放によって引き起こされる問題を解決するためのものです。このモデルをデータベース接続管理の分野に適用することは、データベース接続プールを確立し、一連の効率的な接続割り当てと使用戦略を提供することであり、最終的な目標は接続の効率的かつ安全な再利用を達成することです。
• 接続プールのもう 1 つの副作用は、高可用性を実現することです。マイクロサービス シナリオでは、接続が使用できない場合は、netty 接続プールから別の接続を取得して使用し、接続が使用できない問題を回避します。

各接続プールの構築および利用管理の詳細なプロセスは、大きく次の 3 つの部分に分かれています。

• まず接続プールを初期化します。対応するパラメータ セットに従って、接続プール サイズ、コア スレッドの数、コア接続の数、その他のパラメータに従って、データベース、http、netty 接続、jdk スレッドを初期化して作成します。
• 接続プールの使用: 先に初期化した接続プールとスレッド プールは、接続プールとスレッドからリソースを取り出して直接使用できます。使用後は忘れずに接続プールとスレッド プールを返却し、プール コンテナを通じてリソースを管理します。
• 接続プールのメンテナンスの場合: 接続プールとスレッド プールは接続とスレッドのステータスを維持するために使用され、使用できない接続とスレッドは破棄され、接続とスレッドは状態のマーキングに使用されます。接続とスレッドが十分でなく、最大値を下回った後は、接続とスレッドの数を設定する必要があります。 新しい接続を作成し、スレッドを作成します。

4. コネクションプールの実装

• データベース接続プールの基本原理は、内部のオブジェクト プールで一定数のデータベース接続を維持し、データベース接続の取得メソッドと返却メソッドを外部に公開することです。
• 外部ユーザーは、getConnection メソッドを介して接続を取得し、使用後に close メソッドを介して接続を返すことができます。この時点では、接続は閉じられませんが、接続プール マネージャーによってリサイクルされ、次回の使用の準備が整います。
• Java には DataSource インターフェイスがあり、データベース接続プールは DataSource の実装です。

5. データベース接続プール

1) 定義と理解:

• データベース接続プールの基本的な考え方は、データベース接続用の「バッファ プール」を作成することです。データベース接続を確立する必要がある場合は、事前に一定数の接続をバッ​​ファ プールに入れておくだけで済みます。 「バッファプール」から1つを取り出し、使用後は元に戻します
• データベース接続プールはデータベース接続の割り当て、管理、解放を担当します。これにより、アプリケーションはデータベース接続を再確立するのではなく、既存のデータベース接続を再利用できるようになります。
• データベース接続プールが初期化されると、一定数のデータベース接続が作成され、接続プールに配置されます。
  • データベース接続の数は、データベース接続の最小数によって設定されます。これらのデータベース接続が使用されるかどうかに関係なく、接続プールには少なくともこの数の接続が常に保証されます。
  • 接続プール内のデータベース接続の最大数は、接続プールが占有することができる最大接続数を制限します。アプリケーションによって接続プールから要求された接続数が最大接続数を超えると、これらの要求は接続プールに追加されます。待機列

 2) データベース接続プール技術のメリット

• リソースの再利用 (再利用):データベース接続を再利用できるため、頻繁な接続の作成と解放によって引き起こされる大量のパフォーマンスのオーバーヘッドが回避され、システム消費量が削減され、システムの動作環境の安定性も向上します。
• システムの応答速度の高速化:データベース接続プールの初期化プロセス中に、多くの場合、複数のデータベース接続が作成され、スタンバイ用の接続プールに配置されます。この時点で、接続の初期化が完了しました。ビジネス リクエストの処理では、データベース接続の初期化および解放プロセスの時間オーバーヘッドを回避するために、既存の利用可能な接続が直接使用され、それによってシステムの応答時間が短縮されます。
• リソース割り当ての新しい手段:複数のアプリケーションが同じデータベースを共有するシステムの場合、データベース接続プールの構成をアプリケーション層で構成して、アプリケーションで使用可能なデータベース接続の最大数を制限し、アプリケーションがすべてのデータベース接続を独占するのを防ぐことができます。データベースリソース
• データベース接続リークを回避するための統合接続管理:比較的完全なデータベース接続プールの実装では、事前占有タイムアウト設定に従って占有接続を強制的に回復できるため、従来のデータベース接続操作で発生する可能性のあるリソース リークを回避できます。

3) 2 つのオープンソース データベース接続プール:

• JDBC のデータベース接続プールは javax.sql.DataSource で表されます。DataSource は単なるインターフェイスであり、通常はサーバー (Weblogic、WebSphere、Tomcat) によって実装され、一部のオープン ソース組織も実装を提供しています。
  • DBCP データベース接続プール
  • C3P0 データベース接続プール
• DataSource は通常データ ソースと呼ばれますが、接続プールとも呼ばれ、接続プールと接続プール管理の 2 つの部分で構成されます。
• データ ソースはデータベース接続とは異なります。複数のデータ ソースを作成する必要はありません。データ ソースはデータベース接続を生成するためのファクトリであるため、アプリケーション全体で必要なデータ ソースは 1 つだけです。
• データベースへのアクセスが終了すると、プログラムは以前と同様にデータベース接続を閉じます: conn.close(); しかし、上記のコードはデータベースへの物理的な接続を閉じず、データベース接続を解放してデータベース接続に戻すだけです。プール