3.1TODO

1. 計(jì)算機(jī)網(wǎng)絡(luò)

  1. OSI七層架構(gòu)和TCP五層架構(gòu)
    1. OSI：應(yīng)用、表示、會(huì)話、傳輸、網(wǎng)絡(luò)、數(shù)據(jù)鏈路、物理
    2. TCP：應(yīng)用(報(bào)文)、傳輸(報(bào)文段)、網(wǎng)絡(luò)(分組)、數(shù)據(jù)鏈路(幀)、物理(比特)
  1. TCP五層對應(yīng)的協(xié)議
    1. 應(yīng)用層：為用戶提供交互應(yīng)用服務(wù)。DNS、HTTP、STMP
    2. 傳輸層：在兩臺(tái)主機(jī)之間進(jìn)行通信傳輸數(shù)據(jù)。TCP、UDP
    3. 網(wǎng)絡(luò)層：選擇合適的路由和交換節(jié)點(diǎn)。IP
    4. 數(shù)據(jù)鏈路層：在兩個(gè)相鄰節(jié)點(diǎn)傳輸幀
    5. 物理層：在相鄰節(jié)點(diǎn)間傳輸比特
  1. TCP和UDP的區(qū)別

    1. TCP是面向連接的、可靠的、傳輸字節(jié)流、傳輸效率慢

      1. TCP通過三次握手建立連接，確保雙方能正常收發(fā)數(shù)據(jù)
      2. TCP通過四次揮手?jǐn)嚅_連接，確保雙方都已經(jīng)完成收發(fā)并且數(shù)據(jù)已經(jīng)被成功接收后才斷開連接
      3. 可靠性：通過確認(rèn)、超時(shí)重傳、流量控制、擁塞控制等機(jī)制確保傳輸數(shù)據(jù)的可靠性，即數(shù)據(jù)傳輸不丟包、數(shù)據(jù)無錯(cuò)誤、數(shù)據(jù)順序正確、不重傳
      4. 應(yīng)用：文件傳輸(FTP)、發(fā)送郵件(STMP)

    2. UDP是無連接、不可靠的、傳輸數(shù)據(jù)報(bào)文段、傳輸效率高

      1. 不需要建立連接也不需要斷開連接
      2. 傳輸數(shù)據(jù)只管發(fā)送不管是否成功接收，效率高
      3. 應(yīng)用：發(fā)送語音、直播、視頻
  1. TCP如何保證可靠傳輸

    1. 確認(rèn)：接收方的確認(rèn)報(bào)文ack約定發(fā)送方下一個(gè)報(bào)文的頭部。比如發(fā)送方發(fā)送報(bào)文123，接收方回應(yīng)ack報(bào)文約定發(fā)送方下一個(gè)報(bào)文的頭部必須是4。如果發(fā)送方的下一個(gè)報(bào)文的頭部不為4，接收方可以要求發(fā)送方重發(fā)報(bào)文

    2. 超時(shí)重傳：發(fā)送方發(fā)送了一個(gè)報(bào)文后，如果超過一段時(shí)間都沒有收到接收方的確認(rèn)報(bào)文，會(huì)重發(fā)這個(gè)報(bào)文

    3. 流量控制：如果發(fā)送方發(fā)送數(shù)據(jù)太快，會(huì)導(dǎo)致接收方來不及接收數(shù)據(jù)導(dǎo)致數(shù)據(jù)丟包。通過滑動(dòng)窗口進(jìn)行流量控制，接收方收到數(shù)據(jù)后，根據(jù)自身緩沖區(qū)的大小，將剩余窗口的大小通過確認(rèn)報(bào)文返回給發(fā)送方，發(fā)送方根據(jù)這個(gè)窗口大小確定下一次發(fā)送數(shù)據(jù)的長度

    4. 擁塞控制：也是基于滑動(dòng)窗口實(shí)現(xiàn)，但是是發(fā)送方根據(jù)當(dāng)前網(wǎng)絡(luò)環(huán)境自己估算窗口大小

      1. 慢開始：一開始窗口大小為1，如果網(wǎng)絡(luò)好，大小呈指數(shù)增長
      2. 擁塞避免：因?yàn)槭浅手笖?shù)增長，當(dāng)窗口大小達(dá)到閾值時(shí)，開始呈線性增長。當(dāng)出現(xiàn)網(wǎng)絡(luò)擁塞時(shí)，窗口大小降為1，重新開始慢開始
      3. 快重傳：當(dāng)發(fā)送方接收到三個(gè)重復(fù)的確認(rèn)報(bào)文后，無需等待，直接重傳下一個(gè)報(bào)文
      4. 快恢復(fù)：窗口大小降為快重傳發(fā)生時(shí)的1/2
  1. 三次握手、四次揮手

    1. 三次握手：假設(shè)發(fā)送方為客戶端，接收方為服務(wù)端

      1. 客戶端向服務(wù)端發(fā)起建立連接請求，客戶端生成一個(gè)序列號(hào)seq=x，將標(biāo)志位SYN=1和序列號(hào)seq=x發(fā)送給服務(wù)器端。此時(shí)客戶端狀態(tài)為SYN_SENT，服務(wù)端狀態(tài)為LISTEN
      2. 服務(wù)端收到客戶端的報(bào)文后，服務(wù)端生成一個(gè)序列號(hào)seq=y，將標(biāo)志位SYN=1，序列號(hào)seq=y，確認(rèn)報(bào)文ACK=1，確認(rèn)號(hào)ack=x+1發(fā)送給客戶端。此時(shí)客戶端狀態(tài)為SYN_SENT，服務(wù)端狀態(tài)為SYN_RECV
      3. 客戶端收到服務(wù)端的報(bào)文后，客戶端生成序列號(hào)seq=x+1，將標(biāo)志位ACK=1，序列號(hào)seq=x+1，確認(rèn)號(hào)ack=y+1發(fā)送給服務(wù)端。此時(shí)客戶端狀態(tài)為ESTABLISHED，服務(wù)器收到報(bào)文后，狀態(tài)也為ESTABLISHED

    2. 四次揮手

      1. 當(dāng)客戶端發(fā)送完報(bào)文后，客戶端向服務(wù)端發(fā)送終止報(bào)文(標(biāo)志位FIN=1，序列號(hào)seq=u)，客戶端進(jìn)入FIN_WAIT1狀態(tài)
      2. 服務(wù)端收到終止報(bào)文，服務(wù)端向客戶端發(fā)送確認(rèn)報(bào)文(標(biāo)志位ACK=1，序列號(hào)seq=v，確認(rèn)號(hào)ack=u+1)，服務(wù)端進(jìn)入CLOSE_WAIT狀態(tài)
      3. 服務(wù)端此時(shí)還會(huì)繼續(xù)發(fā)送剩余的未發(fā)送的數(shù)據(jù)，當(dāng)數(shù)據(jù)發(fā)送完后，服務(wù)端向客戶端發(fā)送終止報(bào)文(標(biāo)志位FIN=1，標(biāo)志位ACK=1，序列號(hào)seq=w，確認(rèn)號(hào)ack=u+1)，服務(wù)端進(jìn)入LAST_ACK狀態(tài)
      4. 客戶端收到服務(wù)端的終止報(bào)文后，向服務(wù)端發(fā)送確認(rèn)報(bào)文(標(biāo)志位ACK=1，序列號(hào)seq=u+1，確認(rèn)號(hào)ack=w+1)，客戶端進(jìn)入TIME_WAIT狀態(tài)，等待2MSL時(shí)間后，客戶端進(jìn)入CLOSE狀態(tài)，當(dāng)服務(wù)端收到客戶端的確認(rèn)報(bào)文后，服務(wù)端也進(jìn)入CLOSE狀態(tài)，服務(wù)端早于客戶端進(jìn)入CLOSE狀態(tài)
  1. 為什么是三次握手，兩次是否可以
    1. 假設(shè)只有兩次握手，那么如果第二次握手的時(shí)候，服務(wù)端返回給客戶端的確認(rèn)報(bào)文丟失了，客戶端沒有收到確認(rèn)報(bào)文，認(rèn)為沒有建立連接，但是服務(wù)端把報(bào)文發(fā)送出去了，認(rèn)為已經(jīng)建立了連接，但是實(shí)際連接是沒有成功建立
    2. 假設(shè)只有兩次握手，那么第一次客戶端發(fā)送的請求建立連接的報(bào)文沒有丟失，而是因?yàn)槌瑫r(shí)重傳，后面又發(fā)送了一次，如果只有兩次握手，當(dāng)服務(wù)端收到請求建立連接的報(bào)文后，又會(huì)建立另一個(gè)連接，但是這個(gè)連接不會(huì)進(jìn)行數(shù)據(jù)傳輸
  1. 為什么連接的時(shí)候是三次，斷開連接卻要四次
    1. 當(dāng)服務(wù)端收到客戶端的終止報(bào)文后，回復(fù)確認(rèn)報(bào)文之后，服務(wù)端要將剩余的數(shù)據(jù)繼續(xù)發(fā)送完才會(huì)發(fā)送終止報(bào)文給客戶端，這樣能保證數(shù)據(jù)傳輸?shù)耐暾?/li>
  1. 為什么第四次揮手時(shí)發(fā)出的確認(rèn)報(bào)文要等到2MSL時(shí)間才能釋放TCP連接
    1. 因?yàn)镸SL是報(bào)文在傳輸時(shí)存活的最長時(shí)間，當(dāng)?shù)谒拇螕]手時(shí)客戶端發(fā)送的確認(rèn)報(bào)文達(dá)到服務(wù)端，服務(wù)端再返回確認(rèn)報(bào)文，最長時(shí)間就是2MSL，如果超過2MSL還沒有收到服務(wù)端返回的確認(rèn)報(bào)文，就說明客戶端發(fā)送的報(bào)文丟失了，要重傳，否則服務(wù)端無法關(guān)閉連接
  1. HTTP和HTTPS
    1. HTTP端口80，HTTPS端口443
    2. HTTP無加密，HTTPS通過數(shù)字證書進(jìn)行加密
    3. HTTP基于TCP協(xié)議，傳輸明文內(nèi)容。HTTPS基于SSL協(xié)議，傳輸加密數(shù)據(jù)
  1. HTTP的請求有哪些：GET、POST、DELETE、PUT
    1. PUT：上傳文件
    2. DELETE：刪除文件
    3. POST：提交數(shù)據(jù)，修改
    4. GET：獲取數(shù)據(jù)，查詢
  1. HTTP狀態(tài)碼：200——成功、404——找不到、500——服務(wù)端錯(cuò)誤
  1. HTTP1.0、HTTP1.1、HTTP2.0（長連接和短連接）
    1. 1.0默認(rèn)采用短連接，每次傳輸數(shù)據(jù)都要通過三次握手建立TCP連接，數(shù)據(jù)傳輸完畢后就通過四次揮手?jǐn)嚅_連接
    2. 1.1采用長連接，在一個(gè)TCP連接存活的keepAlive時(shí)間里，可以多次使用該連接傳輸數(shù)據(jù)
  1. HTTP請求過程（從網(wǎng)址欄輸入U(xiǎn)RL到顯示主頁的過程）
    1. 對輸入的url進(jìn)行DNS解析，將域名轉(zhuǎn)換為IP地址
    2. 和目標(biāo)服務(wù)器建立TCP連接
    3. 向目標(biāo)服務(wù)器發(fā)送HTTP請求
    4. 目標(biāo)服務(wù)器處理請求并返回HTTP報(bào)文
    5. 瀏覽器解析并渲染頁面
  1. HTTPS請求過程（HTTPS加密過程）
    1. 客戶端和服務(wù)端經(jīng)過三次握手建立連接后，客戶端會(huì)發(fā)送一個(gè)請求給服務(wù)端，告訴服務(wù)端，客戶端支持的SSL版本、加密算法和密鑰長度
    2. 服務(wù)端將公鑰發(fā)給數(shù)字證書機(jī)構(gòu)，得到公鑰證書，服務(wù)端將公鑰證書發(fā)給客戶端
    3. 客戶端收到證書后先校驗(yàn)證書是否有效，然后生成對稱密鑰，將對稱密鑰發(fā)送給服務(wù)端
    4. 服務(wù)端收到對稱密鑰后，使用私鑰進(jìn)行解密
    5. 然后客戶端跟服務(wù)端就可以通過對稱加密進(jìn)行通信
  1. 對稱加密和非對稱加密
    1. 對稱加密：加密和解密使用同一個(gè)密鑰，運(yùn)算快，但是要安全將密鑰傳輸給另一方，DES、AES
    2. 非對稱加密：公鑰加密的信息只能用私鑰解密，私鑰加密的信息只能用公鑰解密。RSA
  1. 重定向和轉(zhuǎn)發(fā)
    1. 重定向，是客戶端行為，瀏覽器根據(jù)服務(wù)端返回的狀態(tài)碼（3xx），對重定向的URL重新發(fā)起HTTP請求，URL會(huì)發(fā)生變化，不能共享數(shù)據(jù)?？梢杂糜谟脩糇N后重定向到登錄頁面
    2. 轉(zhuǎn)發(fā)，是服務(wù)端行為，URL不會(huì)發(fā)生變化，轉(zhuǎn)發(fā)和被轉(zhuǎn)發(fā)頁面可以共享request請求頭的數(shù)據(jù)。可以用于用戶登錄后將user數(shù)據(jù)轉(zhuǎn)發(fā)到指定頁面
  1. session、cookie、token

    1. 因?yàn)镠TTP協(xié)議是無狀態(tài)的，也就是客戶端每次想要和服務(wù)端通信，都要重新建立連接。cookie、session、token都是為了校驗(yàn)用戶

    2. cookie：

      1. 流程：客戶端請求服務(wù)端，服務(wù)端生成一個(gè)session，將sessionid設(shè)置到cookie，返回給客戶端瀏覽器保存。
      2. 特點(diǎn)：大小在4KB左右，瀏覽器每次請求都會(huì)在請求頭攜帶cookie
      3. 缺點(diǎn)：不安全，存放在瀏覽器，可以被查看

    3. session

      1. 流程：客戶端請求服務(wù)端，服務(wù)端生成一個(gè)session，保存到數(shù)據(jù)庫，然后將sessionid設(shè)置到cookie，返回給客戶端瀏覽器。下一次請求時(shí)，通過cookie存放的sessionid校驗(yàn)
      2. 特點(diǎn)：存放在服務(wù)端，存儲(chǔ)空間大
      3. 優(yōu)點(diǎn)：安全，存放在服務(wù)端
      4. 缺點(diǎn)：session相當(dāng)于存了整個(gè)用戶信息

    4. token

      1. 流程：客戶端請求服務(wù)端，服務(wù)端校驗(yàn)通過后，將用戶id和其他一些信息進(jìn)行加密，生成token，保存到緩存或者數(shù)據(jù)庫，然后將token返回給客戶端，客戶端下一次請求時(shí)把token帶上，服務(wù)端校驗(yàn)token是否通過
      2. 特點(diǎn)：體積小，是一段加密的字符
      3. 優(yōu)點(diǎn)：安全，存放在服務(wù)端，且只存了用戶id，可以通過緩存層實(shí)現(xiàn)不需要去數(shù)據(jù)庫查詢用戶
  1. 如果客戶端禁止cookie，session還能用嗎
    1. 也可以，雖然session一般是通過將sessionid存放在cookie中實(shí)現(xiàn)的，但是如果cookie被禁用了，也可以將sessionid通過url傳遞，也能實(shí)現(xiàn)校驗(yàn)
  1. ping命令做了什么，是基于哪一層
    1. ping命令主要用來測試兩臺(tái)主機(jī)之間的連通性
    2. 原理：向目的主機(jī)發(fā)送請求報(bào)文，目的主機(jī)收到后發(fā)送回應(yīng)報(bào)文，根據(jù)收發(fā)時(shí)間和成功響應(yīng)的次數(shù)計(jì)算往返時(shí)間和丟包率
    3. 工作在網(wǎng)絡(luò)層

2. 操作系統(tǒng)

  1. CPU占用過高排查
    1. top命令查看當(dāng)前服務(wù)器的cpu、內(nèi)存占用情況
    2. 輸入P命令，查看CPU占用最高的進(jìn)程
    3. top -H -p [進(jìn)程id]：查看進(jìn)程的線程
    4. printf "%x\n" [進(jìn)程id]，得到線程的16進(jìn)制id
    5. jstack [進(jìn)程id] | grep -A100 [線程id]
  1. 常用的Linux命令
    1. 查看目錄：ls
    2. 當(dāng)前路徑：pwd
    3. 查看文件：cat
      1. 查看前50行：cat xx.log | head -n 50
      2. 查看后50行：cat xx.log | tail -n 50
    4. 查詢文件：grep
      1. grep --c "xxx" xx.log

3. Spring：https://zhuanlan.zhihu.com/p/551246463

  1. Spring特點(diǎn)
    1. 輕量級：jar包
    2. 控制反轉(zhuǎn)：通過IOC機(jī)制，將一個(gè)對象依賴的其他對象也會(huì)通過被動(dòng)的方式加載到IOC容器，不需要對象自己創(chuàng)建或查找依賴對象
    3. 面向切面：AOP
    4. 容器：IOC容器管理IocBean
  1. Spring核心模塊
    1. Spring-core核心包
    2. Spring-context上下文
    3. Spring-aop
    4. Spring-dao
    5. Spring-orm
    6. Spring-web
    7. Spring-mvc
  1. Spring注解

    1. 標(biāo)記Bean相關(guān)注解

      1. @Component
      2. @Controller：控制層，標(biāo)記一個(gè)類作為mvc控制器
      3. @Service：業(yè)務(wù)層，標(biāo)記一個(gè)類作為服務(wù)類
      4. @Repository：持久層，標(biāo)記一個(gè)類作為數(shù)據(jù)訪問對象
      5. @Bean：在方法上使用，該方法要注冊為上下文context中的bean

    2. 注入Bean相關(guān)注解

      1. @Autowired：由bean提供，按類型匹配，如果存在多個(gè)，再按名稱匹配
      2. @Inject：由JSR-330提供，按類型匹配
      3. @Resource：由JSR-250提供，按名稱匹配，如果存在多個(gè)，再按類型匹配

    3. Java配置相關(guān)注解

      1. @Configuration：標(biāo)記一個(gè)類為配置類

    4. AOP相關(guān)注解

      1. @Aspect：標(biāo)記一個(gè)類為切面類
      2. @Before：標(biāo)記在方法上，在該方法執(zhí)行之前執(zhí)行
      3. @After：標(biāo)記在方法上，在該方法執(zhí)行之后執(zhí)行
      4. @Around：標(biāo)記在方法上，在該方法執(zhí)行之前和執(zhí)行之后執(zhí)行
  1. Spring與第三方框架結(jié)合
    1. 權(quán)限：Shiro
    2. 緩存：Redis
    3. 持久化：Mybatis
  1. 什么是SpringIoc
    1. 也就是控制反轉(zhuǎn)。我們可以把這個(gè)詞拆開，分別看看控制什么，反轉(zhuǎn)了什么
      1. 控制：控制對象的創(chuàng)建、管理、銷毀，也就是控制了對象的生命周期
      2. 反轉(zhuǎn)：傳統(tǒng)方式下對象是通過new創(chuàng)建的，然后我們再通過使用實(shí)例對象操作，而Spring是通過一個(gè)Ioc容器，將對象初始化出來放到容器里，我們使用的時(shí)候不需要new對象，可以直接從容器中拿出即可使用
  1. 什么是DI依賴注入
    1. 當(dāng)bean之間存在依賴關(guān)系，ioc容器也會(huì)自動(dòng)將依賴對象的實(shí)例進(jìn)行注入，基于反射實(shí)現(xiàn)(newInstance、invoke method)
      1. 接口注入
      2. setter注入
      3. 構(gòu)造器注入
  1. 什么是Bean：被Ioc容器管理的對象，一般可以通過application.xml配置文件或者使用注解將一個(gè)類標(biāo)注為Bean
  1. 將一個(gè)類聲明為bean的注解
    1. @Component：通用注解，如果一個(gè)類不知道被標(biāo)記為哪個(gè)層，可以使用這個(gè)注解
    2. @Service：業(yè)務(wù)層，業(yè)務(wù)邏輯代碼
    3. @Repository：持久層dao，操作數(shù)據(jù)庫
    4. @Controller：mvc控制層，用于接收客戶端請求并調(diào)度Service業(yè)務(wù)邏輯
  1. @Component和@Bean的區(qū)別
    1. @Component用于類，@Bean用在方法
    2. @Component是通過@ComponentScan注解掃描類路徑自動(dòng)裝配到ioc容器的，@Bean則是告訴Spring這是某個(gè)類的實(shí)例，在需要使用時(shí)給我
    3. 當(dāng)使用第三方庫的類需要裝配到Spring容器時(shí)，只能使用@Bean
  1. 注入Bean的注解有哪些
    1. @Autowired：spring提供
    2. @Inject：JSR-250
    3. @Resource：JSR-330
  1. @Autowired和@Resource的區(qū)別是什么
    1. @Autowired是spring內(nèi)置的注解，默認(rèn)根據(jù)bean的類型匹配，可配置@Qualifier指定bean的name根據(jù)名稱匹配
    2. @Resource是JDK的JSR-330，默認(rèn)根據(jù)bean的名稱匹配，有name和type兩個(gè)參數(shù)可以指定
  1. Bean的作用域
    1. Singleton：單例模式，在整個(gè)IOC容器中，只有一個(gè)Bean實(shí)例
    2. protoType：原型模式，也就是多例，每次通過getBean()獲取Bean都會(huì)創(chuàng)建一個(gè)新的Bean實(shí)例
    3. request：每次HTTP請求，都會(huì)創(chuàng)建不同的Bean實(shí)例
    4. session：每次HTTP Session請求，都會(huì)創(chuàng)建不同的Bean實(shí)例
    5. global session：使用HTTP Session的都只有一個(gè)Bean實(shí)例
    6. Controller是singleton，因?yàn)橐话悴粫?huì)在controller定義屬性
  1. Bean的生命周期
    1. 實(shí)例化：對應(yīng)傳統(tǒng)方式的構(gòu)造函數(shù)。通過XML配置文件、注解等方式，將定義好的Bean對象轉(zhuǎn)換為BeanDefination對象，完成對Bean對象的解析和加載，通過反射機(jī)制newInstance()創(chuàng)建Bean對象
    2. 屬性設(shè)置：對應(yīng)傳統(tǒng)方式的getter和setter方法。這階段會(huì)進(jìn)行依賴注入，將Bean對象依賴的其他Bean對象也加載到Ioc容器
    3. 初始化：AOP
      1. 調(diào)用aware接口相關(guān)方法，invokeAwareMethod()
      2. 調(diào)用BeanPostProcessor的前置處理方法
      3. 調(diào)用initMethod方法
      4. 調(diào)用BeanPostProcessor的后置處理方法
    4. 使用
    5. 銷毀：調(diào)用destoryMethod()方法
  1. 什么是SpringAop
    1. 在傳統(tǒng)方式下，進(jìn)行事務(wù)管理，比如try/catch/finaly這些代碼，或者在業(yè)務(wù)邏輯前后輸出日志，要寫重復(fù)的代碼。aop就是為了簡化這些重復(fù)代碼而出現(xiàn)的概念
    2. 通過橫向抽取的概念，把這些重復(fù)的代碼抽取到一個(gè)切面，通過切面的切入，實(shí)現(xiàn)在不同類的方法中加入事務(wù)管理、日志打印等功能
    3. 業(yè)務(wù)場景
      1. 在CRUD操作中打印每個(gè)操作的開始和結(jié)束日志：@Before、@After
      2. 在CRUD操作出現(xiàn)報(bào)錯(cuò)時(shí)回滾操作：@AfterThrowing
      3. 在CRUD操作后關(guān)閉數(shù)據(jù)庫連接：@After
      4. 統(tǒng)計(jì)CRUD操作的執(zhí)行時(shí)長：@Around
  1. aop的兩種代理方式：通過動(dòng)態(tài)代理，使得在程序運(yùn)行時(shí)可以動(dòng)態(tài)添加新的邏輯和功能

    1. JDK動(dòng)態(tài)代理：當(dāng)目標(biāo)對象實(shí)現(xiàn)了一個(gè)接口時(shí)，使用JDK動(dòng)態(tài)代理。通過newInstance()方法創(chuàng)建代理對象，通過invoke()方法插入額外的邏輯和功能，基于反射機(jī)制

    2. CGLIB代理：當(dāng)目標(biāo)對象沒有實(shí)現(xiàn)接口，使用CGLIB代理，基于字節(jié)碼文件實(shí)現(xiàn)

  1. 什么是SpringMVC
    1. Model模型：負(fù)責(zé)數(shù)據(jù)的讀取、操作、存儲(chǔ)
    2. View視圖：負(fù)責(zé)數(shù)據(jù)的展示，web頁面
    3. Controller控制器：負(fù)責(zé)在Model和View之間進(jìn)行數(shù)據(jù)傳遞
  1. SpringMvc核心組件
    1. DispatchServlet：前端控制器，負(fù)責(zé)統(tǒng)一處理前端的請求和將請求轉(zhuǎn)發(fā)分配
    2. HandleMapping：將請求路徑映射到對應(yīng)的處理請求的控制器，使用@RequestMapping注解定義路徑
    3. Controller：實(shí)際處理請求的控制器，對請求進(jìn)行業(yè)務(wù)邏輯處理
    4. HanldeAdapter：負(fù)責(zé)將請求分派給控制器進(jìn)行處理
    5. ViewResolver：負(fù)責(zé)將邏輯視圖解析為實(shí)際的視圖對象
    6. View：視圖，負(fù)責(zé)渲染并展示最終的響應(yīng)內(nèi)容
  1. SpringMvc工作流程
    1. 前端請求發(fā)送到前端控制器DispatcherServlet
    2. DispatcherServlet收到請求后調(diào)用處理映射器HandlerMapping
    3. HandlerMapping根據(jù)映射的url路徑找到對應(yīng)的后端處理控制器Controller，將處理器對象返回給前端控制器DispatcherServlet
    4. DispatcherServlet再調(diào)用處理適配器HandlerAdapter調(diào)用對應(yīng)的后端控制器Controller（這里才是真正執(zhí)行后端的業(yè)務(wù)邏輯）
    5. Controller處理完之后，將ModelAndView結(jié)果返回給處理適配器HandlerAdapter
    6. HandleAdapter把ModelAndView返回給前端控制器DispatcherServlet
    7. DispatcherServlet再調(diào)用視圖解析器ViewResolver解析ModelAndView
    8. ViewResolver將ModelAndView的解析結(jié)果返回給View
    9. View渲染并展示響應(yīng)結(jié)果

  1. SpringBoot的優(yōu)點(diǎn)

    1. properties配置文件和yml配置文件使得項(xiàng)目的配置更簡便
    2. 內(nèi)置了TOMCAT

  2. SpringBoot配置文件：properties文件和yml文件

  3. SpringBoot核心注解

    1. @SpringBootConfiguration：啟動(dòng)類的注解
    2. @EnableAutoConfiguration：打開自動(dòng)配置的功能
    3. @ComponentScan：Spring組件掃描。

4. Mybatis:(https://www.zhihu.com/people/zhao-yin-jing/posts)

  1. 注解實(shí)現(xiàn)動(dòng)態(tài)SQL:(https://blog.csdn.net/qq_43494025/article/details/89791321)
    1. @Select(SQL)、@Insert(SQL)、@Update(SQL)、@Delete(SQL)
    2. 動(dòng)態(tài)SQL：@SelectProvider(type="SQLProviderClass",method="SQLProviderMethod")

  1. 優(yōu)點(diǎn)：

    1. 相比于JDBC，簡化了代碼，通過配置文件實(shí)現(xiàn)數(shù)據(jù)庫連接，封裝了JDBC加載驅(qū)動(dòng)、創(chuàng)建連接等繁瑣的復(fù)雜操作，只需要關(guān)注如何編寫SQL語句
    2. 可以通過XML或者注解的方式來配置mapper映射

  2. {}和${}的區(qū)別

    1. {}是預(yù)處理，可以防止SQL注入，安全性高

    2. ${}是字符串替換

4. Nutz框架

  1. （Nutz的mvc流程）項(xiàng)目中如何通過type協(xié)議號(hào)，定位到對應(yīng)的執(zhí)行方法的（底層還是根據(jù)反射，先將facade方法注冊到一個(gè)map里，key是type協(xié)議號(hào)，value是method方法，然后根據(jù)前端請求的參數(shù)type，從map中拿到對應(yīng)的method，然后反射invoke執(zhí)行方法，將方法執(zhí)行結(jié)構(gòu)的res返回）

    1. 起服時(shí)，在MessageDispatcher類中，掃包，檢測使用了@Packet注解標(biāo)注的Facade方法，都其標(biāo)注的type協(xié)議號(hào)作為key，Method方法作為value，存入map中

    2. 當(dāng)前端發(fā)送請求時(shí)，在MessageDispatcher類中，根據(jù)請求參數(shù)協(xié)議號(hào)type，從map拿到對應(yīng)的Method，new MessageFacadeInvoker(msg, callback)，將msg請求參數(shù)和Method方法交給MessageFacadeInvoker反射執(zhí)行類

    3. MessageFacadeInvoker類的run方法執(zhí)行，調(diào)用handleMessage(reqMsg,MethodCallback)

    4. 在handleMessage()方法中，先執(zhí)行methodCallback.handle()通過this.method.invoke()執(zhí)行方法

    5. 根據(jù)方法執(zhí)行返回的Res，填充本次請求的返回

  1. NutzMvc
    后臺(tái)請求處理：https://blog.csdn.net/weixin_43358075/article/details/93999678

    1. OperModule后臺(tái)web操作類
      @IocBean
      @At("/opt")
      @Fail("void")
      @Filters({ @By(type = DESDecryptFilter.class), @By(type = InvokeTimeFilter.class) })
      public class OperateModule {

      @At("/recharge")
      @Ok("json")
      public WebResult recharge() {
      ...
      }
      }

    2. @IocBean：表明該類是IOC，會(huì)被解析到IOC容器，可通過@Inject注入其他IOC

    3. @At：指定URL，類似@RequestMapping

    4. @Fail：請求失敗的返回

    5. @Filters：指定過濾器，每個(gè)請求都要經(jīng)過@By(type=filterClass)的過濾

    6. @OK：請求成功后返回給客戶端的數(shù)據(jù)類型

    7. DESDecryptFilter過濾器：

      1. 客戶端發(fā)送的param參數(shù)是一個(gè)用密鑰加密后的參數(shù)
      2. 通過DESCoder解密后才能得到請求的參數(shù)

    8. InvokeTimeFilter過濾器：

      1. 計(jì)算方法從執(zhí)行到完畢的時(shí)間，打印日志
8. Web主模塊
/**
* web主模塊
* 
* @author yaowenhao
* @date 2014年7月12日 下午4:44:02
*/
@Fail("void")
@IocBy(type = GameWebMain.class, args = { "" })
@Modules({ OperateModule.class, SystemModule.class })
public class MainModule {
}

9. @Modules：主模塊
10. @IocBy：指定通過xxx反轉(zhuǎn)注入
  1. NutDao
    1. AbsConfig：抽象配置解析類，所有系統(tǒng)的配置解析類都要繼承這個(gè)抽象類
      1. load()時(shí)，注冊NutDao為IocBean
      2. 子類在setValue()時(shí)，通過拼接的表名_小表名，dao從配置數(shù)據(jù)庫中讀取對應(yīng)的表（dao.query(tableName))，將表數(shù)據(jù)轉(zhuǎn)換為List<Record>，然后根據(jù)各個(gè)字段的@Config和對應(yīng)的解析方法，通過反射機(jī)制調(diào)用解析方法解析表字段配置
  1. NutIoc

    1. @IocBean：AnnotationIocLoader根據(jù)這個(gè)注解來判斷哪些類應(yīng)該被自己加載

    2. @Inject：AnnotationIocLoader根據(jù)這個(gè)注解來了解類中的字段，具體的注入方式

    3. 使用了@IocBean注解標(biāo)注的class類，在服務(wù)器啟動(dòng)時(shí)，通過AnnotationIocLoader將其轉(zhuǎn)換為IocBean，放到GameWebContext的全局Ioc容器中

    4. @Inject

    5. Json文件：JsonLoader加載server.js配置文件

  1. NutAop
    1. @Aop注解
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 設(shè)計(jì)模式 一.六大設(shè)計(jì)原則 1.開閉原則：針對擴(kuò)展開放，修改關(guān)閉； 2.里氏替換原則：任何父類出現(xiàn)的地方都可由其子...
    說好的蔚藍(lán)天空呢閱讀 663評論 0贊 0
  • 歡迎關(guān)注公眾號(hào)“Tim在路上” 1.聽說你對JVM有點(diǎn)研究，講一講JVM的內(nèi)存模型吧（我說虛擬機(jī)棧，本地方法棧，程...
    Tim在路上閱讀 3,971評論 4贊 91
  • Java繼承關(guān)系初始化順序 父類的靜態(tài)變量-->父類的靜態(tài)代碼塊-->子類的靜態(tài)變量-->子類的靜態(tài)代碼快-->父...
    第六象限閱讀 2,255評論 0贊 9
  • 作者：GarbageCollection 鏈接：https://www.nowcoder.com/discuss/...
    Sonyhandsome閱讀 194評論 0贊 0
  • 從三月份找實(shí)習(xí)到現(xiàn)在，面了一些公司，掛了不少，但最終還是拿到小米、百度、阿里、京東、新浪、CVTE、樂視家的研發(fā)崗...
    時(shí)芥藍(lán)閱讀 42,818評論 11贊 349

友情鏈接更多精彩內(nèi)容