2）監(jiān)聽屬性需要在web.xml中配置

3）監(jiān)聽session對象狀態(tài)不需要在web.xml中配置

(一)鈍化：當服務(wù)器正常關(guān)閉時,還存活著的session(在設(shè)置時間內(nèi)沒有銷毀) 會隨著服務(wù)器的關(guān)閉被以文件(“SESSIONS.ser”)的形式存儲在tomcat 的work 目錄下,這個過程叫做Session 的鈍化。
(二)活化：當服務(wù)器再次正常開啟時,服務(wù)器會找到之前的“SESSIONS.ser” 文件，從中恢復之前保存起來的Session 對象，這個過程叫做Session的活化。

監(jiān)聽器的開發(fā)步驟
1）實現(xiàn)對應(yīng)的接口
2）重寫接口中的方法
3）在web.xml中注冊該listener(根據(jù)監(jiān)聽器類型判斷需不需要)

參考CSDN博主「猿小許」的原創(chuàng)文章，原文鏈接：https://blog.csdn.net/weixin_44205087/article/details/117923765。

2.1.6、 請求轉(zhuǎn)發(fā)和請求重定向

轉(zhuǎn)發(fā)與重定向?qū)崿F(xiàn)的功能是相同的，用于從一個頁面跳轉(zhuǎn)到另一個頁面。但是從內(nèi)部細節(jié)上有很大的不同。
請求轉(zhuǎn)發(fā)(forward)：發(fā)生在服務(wù)端程序內(nèi)部，由服務(wù)器進行的頁面跳轉(zhuǎn)，因此也叫服務(wù)器內(nèi)部轉(zhuǎn)發(fā)；當服務(wù)器端收到一個客戶端的請求之后，會先將請求轉(zhuǎn)發(fā)給目標地址，再將目標地址返回的結(jié)果轉(zhuǎn)發(fā)給客戶端， 而客戶端對于這一切毫無感知的。
轉(zhuǎn)發(fā)的特點：
1）轉(zhuǎn)發(fā)是服務(wù)器內(nèi)部的行為，因此在轉(zhuǎn)發(fā)時，客戶端請求的地址不會發(fā)生變化，即使服務(wù)器內(nèi)部已經(jīng)跳轉(zhuǎn)了好幾次了，但是客戶端訪問的地址依舊不變；
2）整個轉(zhuǎn)發(fā)過程中，客戶端從始至終只發(fā)送了一次請求；
3）由于在整個轉(zhuǎn)發(fā)過程中，客戶端只發(fā)送了一次請求，因此請求域的數(shù)據(jù)不會失效；
4）轉(zhuǎn)發(fā)是服務(wù)器內(nèi)部的行為，因此我們不需要加上項目名；例如：request.getRequestDispatcher("/demo01")
轉(zhuǎn)發(fā)示例：客戶端訪問資源/demo01，服務(wù)器發(fā)現(xiàn)客戶端想要的資源不在/demo01于是自己將請求轉(zhuǎn)發(fā)到/demo02，這個過程客戶端無感知；客戶端只請求了一次；

請求轉(zhuǎn)發(fā)圖解

請求重定向：服務(wù)器端接收到客戶端的請求之后，會給客戶端返回了一個臨時響應(yīng)頭，這個臨時響應(yīng)頭中記錄了客戶端需要再次發(fā)送請求(重定向)的 URL 地址，客戶端根據(jù)服務(wù)器反饋的信息再次請求服務(wù)器，這就是請求重定向。
重定向的特點：
1）由于客戶端重定向是客戶端再次請求，因此客戶端的地址欄的地址已經(jīng)發(fā)生了變化；
2）客戶端請求了兩次服務(wù)器
3）在整個重定向過程中，客戶端發(fā)送了兩次請求，請求域中的數(shù)據(jù)丟失；
4）重定向是客戶端行為（客戶端再次請求），我們需要加上項目名；例如：sendRedirect("request.getContextPath()+/demo01")
如果需要保留請求域中的數(shù)據(jù)，使用轉(zhuǎn)發(fā)，否則使用重定向。
重定向示例：客戶端首先訪問資源/demo01，服務(wù)器發(fā)現(xiàn)想要的資源不在demo01這里，于是告訴（sendRedirect）客戶端："你要的資源不在我這里，你去訪問/demo02"吧！于是客戶端再次訪問資源/demo02；在重定向中，客戶端已經(jīng)請求了兩次服務(wù)器。

請求重定向圖解

2.2、服務(wù)層(Service)：

開發(fā)人員主動管理對象。

2.3、 數(shù)據(jù)訪問層(DAO)：

Java Database Connectivity，簡稱JDBC；是Java語言中用來規(guī)范客戶端程序如何來訪問數(shù)據(jù)庫的應(yīng)用程
序接口，提供了諸如查詢和更新數(shù)據(jù)庫中數(shù)據(jù)的方法。

2.3.1、 JDBC的優(yōu)點：

1. JDBC API是一組接口，沒有具體的實現(xiàn)。實現(xiàn)類由各數(shù)據(jù)庫廠商去實現(xiàn)。只需要調(diào)用接口中
   的方法即可。
2. JDBC代碼只需要少量的修改就可以訪問另一種數(shù)據(jù)庫。
3. 所有數(shù)據(jù)庫框架，底層最終都會轉(zhuǎn)成JDBC的代碼來實現(xiàn)。

2.3.2、 JDBC的操作步驟

2.3.2.1、 加載驅(qū)動

Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");

2.3.2.2、 獲得連接

//數(shù)據(jù)庫連接信息，一般配置在.properties文件中
String url = "jdbc:mysql://localhost:3306/project_db?useUnicode=true&characterEncoding=utf-8&useSSL=true&serverTimezone=UTC";
String username= "root";
String password= "abc1234.";
//獲取連接
Connection con = DriverManager.getConnection(url, username, password);

2.3.2.3、 執(zhí)行指令

PreparedStatement ps = con.prepareStatement("select * from studernt");

2.3.2.4、 獲取查詢結(jié)果集(查詢才有,增刪無此步驟)

List<Student> list=new ArrayList<Student>();
rs=ps.executeQuery();
while (rs.next()) {
    Student stu=new Student();
    stu.setId(rs.getInt(1));
    stu.setName(rs.getString(2));
    stu.setAge(rs.getInt(3));
    stu.setBirthday(rs.getDate(4));
    list.add(stu); 
}

2.3.2.5、 關(guān)閉資源

if(con!=null&&!con.isClosed()) {
    con.close();
}
if(ps!=null) {
    ps.close();
}

參考CSDN博主「LJT_1314520」的原創(chuàng)文章，原文鏈接：https://blog.csdn.net/LJT_1314520/article/details/125241649

2.3.3、 SQL注入問題

Statement是先在sql語句中傳值再編譯，存在sql注入問題。
PreparedStatement是先對sql語句進行預(yù)編譯，然后再傳入變量值，預(yù)編譯中的待傳參數(shù)部分用？占位符代替。解決了sql注入

2.3.4、 連接池

原因：每次訪問數(shù)據(jù)庫都必須先創(chuàng)建連接，執(zhí)行完畢以后關(guān)閉連接對象。連接對象需要不停的創(chuàng)建，不停的關(guān)
閉。

問題：
1）數(shù)據(jù)庫創(chuàng)建連接通常需要消耗相對較多的資源，創(chuàng)建時間也較長，而每次操作都要重新獲取新的
連接對象，執(zhí)行一次操作就把連接關(guān)閉，這樣數(shù)據(jù)庫連接對象的使用率低。
2）假設(shè)網(wǎng)站一天10萬訪問量，數(shù)據(jù)庫服務(wù)器就需要創(chuàng)建10萬次連接，極大的浪費數(shù)據(jù)庫的資源，并
且極易造成數(shù)據(jù)庫服務(wù)器內(nèi)存溢出。

作用：
1）提高獲取連接對象的速度；
2）提高連接對象的使用率，每個連接對象可以重復使用。