1。サーブレットの概要
1. Sun Companyが提供する動的Webリソース開発技術。エッセンスは以前のJavaアプレットであり、このアプレットはサーバーがそれを呼び出すことができるようにサーブレットインターフェイスを実装する必要があることが必要です。
2。サーブレットを開発する2つのステップ
*実験：サーブレットのクイックスタート
（1）ステップ1：サーブレットインターフェイスを実装するためにJavaプログラムを作成します（ここでは、デフォルトの実装クラスGenericservletを直接継承します）
パッケージcn.itheima; Import java.io。*; import javax.servlet。*; public class firstServletはgenericservletを拡張します{public void service（servletrequest req、servletresponse res）throws servletexception、java.io.ioexception {res.getotputtream（）。（2）コンパイルされた.classをWeb-inf/classesの下に置くことに加えて、Webアプリケーションのweb.xml登録サーブレットも設定する必要があります。
<サーブレット> servlet-name> firstServlet </servlet-name> <servlet-class> cn.itheima.firstservlet </servlet-class> </servlet> <servlet-name> firstServlet </servet-name> <url-pattern>/firstservlet </url-apternn> </servlet mapping>
3。髄膜込んでサーブレットを開発します
2。サーブレットの詳細な説明
1。ライフサイクル：物が生まれて死んだとき、それは必然的にその存在中に何をするか。それをまとめることは、物の宣言サイクルです。
2。サーブレットのライフサイクル：一般的に、サーブレットに初めてアクセスされると、オブジェクトがメモリで作成され、init（）メソッドは作成直後に呼び出されます。各リクエストについて、サービス（REQ、RESP）メソッドを使用してリクエストを処理します。この時点で、リクエスト情報はリクエストオブジェクトでカプセル化され、応答オブジェクト（元々空）は応答メッセージを表し、使用するサービス方法に渡されます。サービスメソッドが処理されると、Return Server Serverは応答メッセージを整理して、応答の情報に基づいてブラウザに返されます。応答が完了した後、サーブレットは破壊されず、メモリにとどまり、次のリクエストを待ちます。サーバーが閉じられるか、Webアプリケーションが仮想ホストから削除されるまで、サーブレットオブジェクトが破壊され、その後何かを行うために破壊される前にDestroy（）メソッドが呼び出されます。
3。サーブレット界面の継承構造
サーブレットインターフェイス：サーブレットが必要な方法を定義し、すべてのサーブレットがこのインターフェイスを直接または間接的に実装する必要があります。
|
| --- GenericServlet：サーブレットインターフェイスのデフォルトの実装、一般サーブレット、これは抽象クラスであり、ほとんどの方法はデフォルトで実装されます。サービス方法のみは、継承者自身が実装する必要がある抽象的なメソッドです。
|
| ----- httpservlet：HTTPプロトコル用に最適化されたサーブレットはGenericServletクラスから継承され、サービス抽象メソッドが実装されています。デフォルトの実装により、リクエストのリクエストメソッドが決定され、異なるリクエストメソッドに従って異なるdoxxx（）メソッドを呼び出します。通常、httpservletを直接継承できます
4。web.xmlでサーブレットを登録するときに注意すべきこと
4.1 <servlet> <servlet-mapping>タグを使用してサーブレットを登録します
<Servlet> <Servlet-Name> FirstServlet </servlet-name> <servlet-class> cn.itheima.firstservlet </servlet-class>
注：ここで欲しいのは、.javaまたは.class extensionsを含むファイルパスではなく、サーブレットの完全なクラス名です
</servlet> <servlet-mapping> <servlet-name> firstServlet </servlet-name> <url-pattern>/firstServlet </url-pattern> </servlet-mapping>
4.2 1つの<Servlet>は、複数の<サーブレットマッピング>に対応できます
4.3 *一致文字を使用して<serlvet-mapping>を構成できますが、 *.doまたは / / *で終わるパスでなければならないことに注意してください。
〜マッチ文字の導入により、仮想パスが複数のサーブレットマッピングに対応する可能性があります。この時点で、サーブレットが探しているのと最も似ており、 *.doレベルは最も低いです。
4.4 <Servlet>用の<Load-on-startup>サブラベルを構成し、サーバーがサーバーの起動でロードされ、構成された値が起動の順序を指定することを指定できます
サーブレット> <Servlet-Name> Invoker </servlet-name> <servlet-class> org.apache.catalina.servlets.invokerservlet </servlet-class> <load-on-startup> 2 </load-on-startup> </servet>
4.5デフォルトサーブレット：サーブレットの外部アクセスパスが /に設定されている場合、サーブレットはデフォルトのサーブレットであり、他のサーブレットはリクエストを処理しません。
〜デフォルトサーブレットはconf/web.xmlで構成されており、静的リソースへのアクセスとエラーページの出力は、このデフォルトのサーブレットによって処理されます。 DADのweb.xmlでデフォルトのサーブレットを上書きするためにデフォルトのサーブレットを記述すると、静的Webリソースがアクセスできなくなります。したがって、構成は推奨されません。
4.6サーブレットのスレッド安全性の問題
4.6.1通常、サーブレットにはメモリに1つのインスタンスしかリクエストにないため、複数のリクエストが送信されると、複数のスレッドがサーブレットオブジェクトを操作し、スレッドの安全性の問題につながる可能性があります。
（1）Servlvetメンバー変数にスレッドの安全性の問題がある場合があります
*実験：メンバー変数inti = 0を定義します。 doxxx（）メソッドでi ++操作を実行し、出力Iはクライアントに値します。現時点では、遅延が原因でスレッドの安全性の問題が発生する場合があります。
（2）Servetがリソースファイルを操作する場合、複数のスレッドが同じファイルを操作し、スレッドの安全性の問題を引き起こす
*実験：リクエストにはパラメーターが付いており、サーブレットはリクエストパラメーターをファイルに書き込み、ファイルを読み取り、読み取り値をクライアントに印刷します。スレッドの安全性の問題がある場合があります
4.6.2解決策
（1）同期コードブロックを使用して問題を解決します。欠点は、同期コードブロックが同時に1つの要求のみを処理できることであり、これは非常に非効率的であるため、同期コードブロックにはスレッドの安全性の問題を引き起こすコアコードを含める必要があることです。
（2）このサーブレットにsinglethreadmodelインターフェイスを実装します。これはタグインターフェイスです。マークされたサーブレットは、メモリにサーブレットプールを保存します。スレッドが来て、プールにサーブレットオブジェクトの処理がない場合、新しいものが作成されます。プールに無料のサーブレットがある場合は、直接使用してください。これは、スレッドの安全性の問題を実際に解決するものではありません。このインターフェイスは放棄されました。
（3）両方のソリューションは完全ではないため、サーブレットにメンバー変数が表示されないようにしてください。
3。ServletConfig
1。サーブレットの構成を表すオブジェクト。
<Servlet> <Servlet-Name> demo5servlet </servlet-name> <servlet-class> cn.itheima.demo5servlet </servlet-class> <init-param> <param-name> data1 </param-name> <param-value> value1 </param-value> </init-param> </servelet>
次に、サーブレットでthis.getServletConfig（）を使用してServletConfigオブジェクトを取得します。このオブジェクトは、getInitParameter（）およびgetInitParameterNames（）メソッドを提供します。
サーブレットにデッドコンテンツを書きたくない場合は、ここで構成できます。
4。ServleTContext
1.現在のWebアプリケーションを表すオブジェクト。
2。ドメインオブジェクトとして使用され、異なるサーブレット間でデータを転送し、そのスコープはWebアプリケーション全体です。
ライフサイクル：WebアプリケーションがコンテナにロードされたときにWebアプリケーション全体を表すServletContextオブジェクトを作成します。サーバーが閉じられるか、Webアプリケーションがコンテナから削除された場合、ServletContextオブジェクトが破壊されます。
〜ドメイン：ドメインは、データを配置できるボックスとして理解されます。ドメインはドメインと呼ばれるため、可視範囲があります。このドメインのデータは、この範囲内で動作できます。このようなオブジェクトは、ドメインオブジェクトと呼ばれます。
3。web.xmlでは、Webアプリケーション全体の初期化パラメーターを構成し、ServletContextを使用して取得できます。
<context-param> <param-name> param1 </param-name> <param-value> pvalue1 </param-value> </context-param> this.getServletContext（）。getInitParameter（ "param1"）this.getServletContext（）。
4。異なるサーブレット間の転送
this.getServletContext（）。getRequestDispatcher（ "/servlet/demo10servlet"）。
メソッドの実行が完了すると、サービスはサーバーに戻り、サーバーはターゲットサーブレットを呼び出し、リクエストが再現され、前のリクエストのデータがコピーされます。
5.リソースファイルを読み取ります
5.1相対パスは、デフォルトでJava仮想マシンによって開始されたディレクトリであるため、Tomcat/Binディレクトリに対する相対パスを直接書き込むため、リソースを取得できません。絶対的なパスとして書かれている場合、プロジェクトが別の環境に公開されると、絶対的なパスが間違っています。
5.2この問題を解決するために、ServletContextはthis.getServletContext（）。getRealPath（ "/1.properties"）を提供します。 this.getServletContext（）。getResourceAsStream（ "/1.Properties"）。リソースの仮想パスをリソースの実際のパスのストリームに戻します。
5.3非サービスでリソースファイルを取得する場合、ServletContextオブジェクトは使用されず、現時点ではクラスローダーのみを使用できます。
classloader.getResourceasStream（ "../../ 1.Properties"）、このメソッドはクラスローダーを使用してリソースをメモリに直接ロードします。
classLoader.getResource（ "../ 1.Properties"）。getPath（）更新遅延の問題なく、リソースの実際のパスを直接返します。
要約します
上記は、サーブレット開発の技術的基盤について簡単に議論することについてのこの記事のすべての内容であり、誰にとっても役立つことを願っています。興味のある友達は引き続きこのサイトを参照できます：
サーブレットセッションテクノロジーの基本分析
このウェブサイトの他の関連トピックと同様に、欠点がある場合は、それを指摘するためにメッセージを残してください。このサイトへのご支援をありがとうございました！