1、什么是ARQ協(xié)議

自動(dòng)重傳請(qǐng)求（Automatic Repeat-reQuest，ARQ）是OSI模型中數(shù)據(jù)鏈路層和傳輸層的錯(cuò)誤糾正協(xié)議之一。它通過使用確認(rèn)和超時(shí)這兩個(gè)機(jī)制，在不可靠服務(wù)的基礎(chǔ)上實(shí)現(xiàn)可靠的信息傳輸。如果發(fā)送方在發(fā)送后一段時(shí)間之內(nèi)沒有收到確認(rèn)幀，它通常會(huì)重新發(fā)送。ARQ包括停止等待ARQ協(xié)議和連續(xù)ARQ協(xié)議。

停止等待ARQ協(xié)議

停止等待協(xié)議是為了實(shí)現(xiàn)可靠傳輸?shù)模幕驹砭褪敲堪l(fā)完一個(gè)分組就停止發(fā)送，等待對(duì)方確認(rèn)（回復(fù)ACK）。如果過了一段時(shí)間（超時(shí)時(shí)間后），還是沒有收到 ACK 確認(rèn)，說(shuō)明沒有發(fā)送成功，需要重新發(fā)送，直到收到確認(rèn)后再發(fā)下一個(gè)分組。

在停止等待協(xié)議中，若接收方收到重復(fù)分組，就丟棄該分組，但同時(shí)還要發(fā)送確認(rèn)。

優(yōu)缺點(diǎn)：

• 優(yōu)點(diǎn)： 簡(jiǎn)單
• 缺點(diǎn)： 信道利用率低，等待時(shí)間長(zhǎng)

1) 無(wú)差錯(cuò)情況:

發(fā)送方發(fā)送分組,接收方在規(guī)定時(shí)間內(nèi)收到,并且回復(fù)確認(rèn).發(fā)送方再次發(fā)送。

2) 出現(xiàn)差錯(cuò)情況（超時(shí)重傳）:

停止等待協(xié)議中超時(shí)重傳是指只要超過一段時(shí)間仍然沒有收到確認(rèn)，就重傳前面發(fā)送過的分組（認(rèn)為剛才發(fā)送過的分組丟失了）。因此每發(fā)送完一個(gè)分組需要設(shè)置一個(gè)超時(shí)計(jì)時(shí)器，其重傳時(shí)間應(yīng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r(shí)間更長(zhǎng)一些。這種自動(dòng)重傳方式常稱為 自動(dòng)重傳請(qǐng)求 ARQ 。另外在停止等待協(xié)議中若收到重復(fù)分組，就丟棄該分組，但同時(shí)還要發(fā)送確認(rèn)。連續(xù) ARQ 協(xié)議 可提高信道利用率。發(fā)送維持一個(gè)發(fā)送窗口，凡位于發(fā)送窗口內(nèi)的分組可連續(xù)發(fā)送出去，而不需要等待對(duì)方確認(rèn)。接收方一般采用累積確認(rèn)，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)，表明到這個(gè)分組位置的所有分組都已經(jīng)正確收到了。

3) 確認(rèn)丟失和確認(rèn)遲到

• 確認(rèn)丟失 ：確認(rèn)消息在傳輸過程丟失。當(dāng)A發(fā)送M1消息，B收到后，B向A發(fā)送了一個(gè)M1確認(rèn)消息，但卻在傳輸過程中丟失。而A并不知道，在超時(shí)計(jì)時(shí)過后，A重傳M1消息，B再次收到該消息后采取以下兩點(diǎn)措施：1. 丟棄這個(gè)重復(fù)的M1消息，不向上層交付。 2. 向A發(fā)送確認(rèn)消息。（不會(huì)認(rèn)為已經(jīng)發(fā)送過了，就不再發(fā)送。A能重傳，就證明B的確認(rèn)消息丟失）。
• 確認(rèn)遲到 ：確認(rèn)消息在傳輸過程中遲到。A發(fā)送M1消息，B收到并發(fā)送確認(rèn)。在超時(shí)時(shí)間內(nèi)沒有收到確認(rèn)消息，A重傳M1消息，B仍然收到并繼續(xù)發(fā)送確認(rèn)消息（B收到了2份M1）。此時(shí)A收到了B第二次發(fā)送的確認(rèn)消息。接著發(fā)送其他數(shù)據(jù)。過了一會(huì)，A收到了B第一次發(fā)送的對(duì)M1的確認(rèn)消息（A也收到了2份確認(rèn)消息）。處理如下：1. A收到重復(fù)的確認(rèn)后，直接丟棄。2. B收到重復(fù)的M1后，也直接丟棄重復(fù)的M1。 連續(xù)ARQ協(xié)議

連續(xù) ARQ 協(xié)議

可提高信道利用率。發(fā)送方維持一個(gè)發(fā)送窗口，凡位于發(fā)送窗口內(nèi)的分組可以連續(xù)發(fā)送出去，而不需要等待對(duì)方確認(rèn)。接收方一般采用累計(jì)確認(rèn)，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)，表明到這個(gè)分組為止的所有分組都已經(jīng)正確收到了。

優(yōu)缺點(diǎn)：

• 優(yōu)點(diǎn)： 信道利用率高，容易實(shí)現(xiàn)，即使確認(rèn)丟失，也不必重傳。
• 缺點(diǎn)： 不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息。 比如：發(fā)送方發(fā)送了 5條 消息，中間第三條丟失（3號(hào)），這時(shí)接收方只能對(duì)前兩個(gè)發(fā)送確認(rèn)。發(fā)送方無(wú)法知道后三個(gè)分組的下落，而只好把后三個(gè)全部重傳一次。這也叫 Go-Back-N（回退 N），表示需要退回來(lái)重傳已經(jīng)發(fā)送過的 N 個(gè)消息。

2、HTTPS的加密、解密的過程

​ 我們都知道HTTPS能夠加密信息，以免敏感信息被第三方獲取。所以很多銀行網(wǎng)站或電子郵箱等等安全級(jí)別較高的服務(wù)都會(huì)采用HTTPS 協(xié)議。HTTPS其實(shí)是有兩部分組成：HTTP + SSL / TLS，也就是在HTTP上又加了一層處理加密信息的模塊。服務(wù)端和客戶端的信息傳輸都會(huì)通過TLS進(jìn)行加密，所以傳輸?shù)臄?shù)據(jù)都是加密后的數(shù)據(jù)。

1. 客戶端發(fā)起HTTPS請(qǐng)求

這個(gè)沒什么好說(shuō)的，就是用戶在瀏覽器里輸入一個(gè)https網(wǎng)址，然后連接到server的443端口。

2. 服務(wù)端的配置

采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請(qǐng)。區(qū)別就是自己頒發(fā)的證書需要客戶端驗(yàn)證通過，才可以繼續(xù)訪問，而使用受信任的公司申請(qǐng)的證書則不會(huì)彈出提示頁(yè)面(startssl就是個(gè)不錯(cuò)的選擇，有1年的免費(fèi)服務(wù))。這套證書其實(shí)就是一對(duì)公鑰和私鑰。如果對(duì)公鑰和私鑰不太理解，可以想象成一把鑰匙和一個(gè)鎖頭，只是全世界只有你一個(gè)人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個(gè)鎖把重要的東西鎖起來(lái)，然后發(fā)給你，因?yàn)橹挥心阋粋€(gè)人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來(lái)的東西。

3. 傳送證書

這個(gè)證書其實(shí)就是公鑰，只是包含了很多信息，如證書的頒發(fā)機(jī)構(gòu)，過期時(shí)間等等。

4. 客戶端解析證書

這部分工作是有客戶端的TLS來(lái)完成的，首先會(huì)驗(yàn)證公鑰是否有效，比如頒發(fā)機(jī)構(gòu)，過期時(shí)間等等，如果發(fā)現(xiàn)異常，則會(huì)彈出一個(gè)警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個(gè)隨即值。然后用證書對(duì)該隨機(jī)值進(jìn)行加密。就好像上面說(shuō)的，把隨機(jī)值用鎖頭鎖起來(lái)，這樣除非有鑰匙，不然看不到被鎖住的內(nèi)容。

5. 傳送加密信息

這部分傳送的是用證書加密后的隨機(jī)值，目的就是讓服務(wù)端得到這個(gè)隨機(jī)值，以后客戶端和服務(wù)端的通信就可以通過這個(gè)隨機(jī)值來(lái)進(jìn)行加密解密了。

6. 服務(wù)段解密信息

服務(wù)端用私鑰解密后，得到了客戶端傳過來(lái)的隨機(jī)值(私鑰)，然后把內(nèi)容通過該值進(jìn)行對(duì)稱加密。所謂對(duì)稱加密就是，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無(wú)法獲取內(nèi)容，而正好客戶端和服務(wù)端都知道這個(gè)私鑰，所以只要加密算法夠彪悍，私鑰夠復(fù)雜，數(shù)據(jù)就夠安全。

7. 傳輸加密后的信息

這部分信息是服務(wù)段用私鑰加密后的信息，可以在客戶端被還原

8. 客戶端解密信息

客戶端用之前生成的私鑰解密服務(wù)段傳過來(lái)的信息，于是獲取了解密后的內(nèi)容。整個(gè)過程第三方即使監(jiān)聽到了數(shù)據(jù)，也束手無(wú)策。

總結(jié)：

HTTPS 之所以保證數(shù)據(jù)可以安全保密傳輸，就是在建立 TCP 三次握手之后，還需要進(jìn)行一次 SSL/TCL 加解密流程：（包含對(duì)稱加密和非對(duì)稱加密）

• 客戶使用 https 的URL訪問Web服務(wù)器，要求與Web服務(wù)器建立SSL連接。
• 首先服務(wù)器端需要向 CA 申請(qǐng)證書（其實(shí)就是一對(duì)公鑰和私鑰），然后服務(wù)端將私鑰保留，將公鑰發(fā)送給客戶端。
• 客戶端收到公鑰后，先對(duì)公鑰進(jìn)行驗(yàn)證（判斷是否過期，頒發(fā)機(jī)構(gòu)是否存在等）。如果公鑰驗(yàn)證合法，則客戶端生成一個(gè) 隨機(jī)值（作為對(duì)稱加密的密鑰），并將其通過公鑰加密后傳遞給服務(wù)器端。
• 服務(wù)器端收到這個(gè) 被公鑰加密的隨機(jī)值 后，使用私鑰對(duì)其進(jìn)行解密，獲取這一隨機(jī)值。之后，客戶端和服務(wù)器端進(jìn)行數(shù)據(jù)通信時(shí)，就可以通過這一隨機(jī)值作為密鑰，對(duì)稱加密解密要傳輸?shù)臄?shù)據(jù)！（所謂對(duì)稱加密就是，將信息和密鑰通過某種算法混合在一起，這樣除非知道密鑰，不然無(wú)法獲取傳輸?shù)膬?nèi)容）

什么是數(shù)字證書？

作用：解決身份認(rèn)證問題。

過程：借助第三方權(quán)威機(jī)構(gòu) CA（數(shù)字證書認(rèn)證機(jī)構(gòu)），將服務(wù)器公鑰放在數(shù)字證書（由數(shù)字證書認(rèn)證機(jī)構(gòu)辦法）中，只要證書是可信的，公鑰就是可信的。

3、深入理解三次握手、四次揮手流程

兩張動(dòng)圖--帶你搞懂TCP的三次握手與四次揮手

4、Spring AOP 如何實(shí)現(xiàn)（實(shí)現(xiàn)原理）

Sprign AOP 本質(zhì)是通過動(dòng)態(tài)代理來(lái)實(shí)現(xiàn)的（JDK動(dòng)態(tài)代理、CGLIB動(dòng)態(tài)代理），利用截取消息的方式，對(duì)該消息進(jìn)行裝飾，以取代原有對(duì)象。主要有以下幾個(gè)步驟。

1、獲取增強(qiáng)器，(例如被 Aspect 注解修飾的類)。

2、在創(chuàng)建每一個(gè) bean 時(shí)，會(huì)檢查是否有增強(qiáng)器能應(yīng)用于這個(gè) bean，簡(jiǎn)單理解就是該 bean 是否在該增強(qiáng)器指定的 execution 表達(dá)式中。如果是，則將增強(qiáng)器作為攔截器參數(shù)，使用動(dòng)態(tài)代理創(chuàng)建 bean 的代理對(duì)象實(shí)例。

3、當(dāng)我們調(diào)用被增強(qiáng)過的 bean 時(shí)，就會(huì)走到代理類中，從而可以觸發(fā)增強(qiáng)器，本質(zhì)跟攔截器類似。

Spring 的 AOP 有哪幾種創(chuàng)建代理的方式?

Spring 中的 AOP 目前支持 JDK 動(dòng)態(tài)代理和 Cglib 代理。

通常來(lái)說(shuō)：如果被代理對(duì)象實(shí)現(xiàn)了接口，則使用 JDK 動(dòng)態(tài)代理，否則使用 Cglib 代理。另外，也可以通過指定 proxyTargetClass=true 來(lái)實(shí)現(xiàn)強(qiáng)制走 Cglib 代理。

JDK 動(dòng)態(tài)代理和 Cglib 代理的區(qū)別?

1、JDK 動(dòng)態(tài)代理本質(zhì)上是實(shí)現(xiàn)了被代理對(duì)象的接口，而 Cglib 本質(zhì)上是繼承了被代理對(duì)象，覆蓋其中的方法。

2、JDK 動(dòng)態(tài)代理只能對(duì)實(shí)現(xiàn)了接口的類生成代理，Cglib 則沒有這個(gè)限制。但是 Cglib 因?yàn)槭褂美^承實(shí)現(xiàn)，所以 Cglib 無(wú)法代理被 final 修飾的方法或類。

3、在調(diào)用代理方法上，JDK 是通過反射機(jī)制調(diào)用，Cglib是通過FastClass 機(jī)制直接調(diào)用。FastClass 簡(jiǎn)單的理解，就是使用 index 作為入?yún)?，可以直接定位到要調(diào)用的方法直接進(jìn)行調(diào)用。

4、在性能上，JDK1.7 之前，由于使用了 FastClass 機(jī)制，Cglib 在執(zhí)行效率上比 JDK 快，但是隨著 JDK 動(dòng)態(tài)代理的不斷優(yōu)化，從 JDK 1.7 開始，JDK 動(dòng)態(tài)代理已經(jīng)明顯比 Cglib 更快了。

5、摘要算法：HTTPS如何方式數(shù)據(jù)發(fā)生了篡改？

作用：防止數(shù)據(jù)被篡改。

摘要算法：實(shí)現(xiàn)數(shù)據(jù)完整性，能夠?yàn)閿?shù)據(jù)生成獨(dú)一無(wú)二的指紋，指紋用于校驗(yàn)數(shù)據(jù)的完整性，解決了被篡改的風(fēng)險(xiǎn)。

過程

1、客戶端發(fā)送明文前，會(huì)通過摘要算法算出明文的指紋，發(fā)送時(shí)明文和指紋一同加密，發(fā)送給服務(wù)器。

2、服務(wù)器解密后，用相同的摘要算法算出發(fā)送過來(lái)的明文，通過比較客戶端攜帶的指紋和當(dāng)前指紋做比較，若相同，則說(shuō)明數(shù)據(jù)是完整的。

6、介紹一下JVM運(yùn)行時(shí)數(shù)據(jù)區(qū)：堆與棧

JVM棧：

JVM棧是線程私有的，每個(gè)線程創(chuàng)建的同時(shí)都會(huì)創(chuàng)建JVM棧，JVM棧中存放的為當(dāng)前線程中局部基本類型的變量（java中定義的八種基本類型：boolean、char、byte、short、int、long、float、double）， 非基本類型的對(duì)象在JVM棧上僅存放一個(gè)指向堆上的引用地址，JVM棧的空間是在物理內(nèi)存上分配的，而不是從堆上分配。 由于JVM棧是線程私有的，因此其在內(nèi)存分配上非常高效，并且當(dāng)線程運(yùn)行完畢后，這些內(nèi)存也就被自動(dòng)回收。 當(dāng)JVM棧的空間不足時(shí)，會(huì)拋出 StackOverflowError 的錯(cuò)誤，可以通過 -Xss 來(lái)指定棧的大小

堆（Heap） ：

Heap是大家最為熟悉的區(qū)域，它是JVM用來(lái)存儲(chǔ)對(duì)象實(shí)例以及數(shù)組值的區(qū)域，可以認(rèn)為Java中所有通過 new 創(chuàng)建的對(duì)象的內(nèi)存都在此分配， Heap中的對(duì)象的內(nèi)存需要等待GC進(jìn)行回收，Heap在 32 位的操作系統(tǒng)上最大為 2G ，在 64 位的操作系統(tǒng)上則沒有限制， 其大小通過 -Xms 和 -Xmx 來(lái)控制，-Xms 為JVM啟動(dòng)時(shí)申請(qǐng)的最小Heap內(nèi)存，默認(rèn)為物理內(nèi)存的 1/64 但小于 1G，-Xmx 為JVM可申請(qǐng)的最大Heap內(nèi)存，默認(rèn)為物理內(nèi)存的 1/4 ，默認(rèn)當(dāng)空余堆內(nèi)存小于 40% 時(shí)，JVM會(huì)增大Heap的大小到 -Xmx 指定的大小 ，可通過 -XX:MinHeapFreeRatio= 來(lái)指定這個(gè)比例，當(dāng)空余堆內(nèi)存大于 70% 時(shí)，JVM會(huì)將Heap的大小往 -Xms 指定的大小調(diào)整，可通過 -XX:MaxHeapFreeRatio= 來(lái)指定這個(gè)比例， 但對(duì)于運(yùn)行系統(tǒng)而言，為了避免頻繁的Heap Size的大小，通常都會(huì)將 -Xms 和 -Xmx 的值設(shè)成一樣，因此這兩個(gè)用于調(diào)整比例的參數(shù)通常是沒用的。其實(shí)jvm中對(duì)于堆內(nèi)存的分配、使用、管理、收集等有更為精巧的設(shè)計(jì)，具體可以在JVM堆內(nèi)存分析中進(jìn)行詳細(xì)介紹。 當(dāng)堆中需要使用的內(nèi)存超過其允許的大小時(shí)，會(huì)拋出 OutOfMemory 的錯(cuò)誤信息。

7、強(qiáng)引用，軟引用和弱引用的區(qū)別？

在JDK 1.2之后，Java對(duì)引用的概念進(jìn)行了擴(kuò)充，將引用分為強(qiáng)引用（Strong Reference）、軟引用（Soft Reference）、弱引用（Weak Reference）、虛引用（Phantom Reference）四種，這四種引用強(qiáng)度依次逐漸減弱。

• 強(qiáng)引用就是指在程序代碼之中普遍存在的，類似 Object obj = new Object() 這類的引用，只要強(qiáng)引用還存在，垃圾收集器永遠(yuǎn)不會(huì)回收掉被引用的對(duì)象。
• 軟引用用來(lái)描述一些還有用，但并非必需的對(duì)象。對(duì)于軟引用關(guān)聯(lián)著的對(duì)象，在系統(tǒng)將要發(fā)生內(nèi)存溢出異常之前，將會(huì)把這些對(duì)象列進(jìn)回收范圍之中并進(jìn)行第二次回收。如果這次回收還是沒有足夠的內(nèi)存，才會(huì)拋出內(nèi)存溢出異常。 在JDK 1.2之后，提供了 SoftReference 類來(lái)實(shí)現(xiàn)軟引用。
• 弱引用也是用來(lái)描述非必需對(duì)象的，但是它的強(qiáng)度比軟引用更弱一些，被弱引用關(guān)聯(lián)的對(duì)象只能生存到下一次垃圾收集發(fā)生之前。當(dāng)垃圾收集器工作時(shí)，無(wú)論當(dāng)前內(nèi)存是否足夠，都會(huì)回收掉只被弱引用關(guān)聯(lián)的對(duì)象。 在JDK 1.2之后，提供了 WeakReference 類來(lái)實(shí)現(xiàn)弱引用。
• 虛引用也稱為幽靈引用或者幻影引用，它是最弱的一種引用關(guān)系。一個(gè)對(duì)象是否有虛引用的存在，完全不會(huì)對(duì)其生存時(shí)間構(gòu)成影響，也無(wú)法通過虛引用來(lái)取得一個(gè)對(duì)象實(shí)例。 為一個(gè)對(duì)象設(shè)置虛引用關(guān)聯(lián)的唯一目的就是希望能在這個(gè)對(duì)象被收集器回收時(shí)收到一個(gè)系統(tǒng)通知。在JDK 1.2之后，提供了 PhantomReference 類來(lái)實(shí)現(xiàn)虛引用

8、如何減少線程的上下文切換？

多線程競(jìng)爭(zhēng)時(shí)，會(huì)引起上下文切換。

• 無(wú)鎖并發(fā)編程：用一些辦法來(lái)避免使用鎖，如將數(shù)據(jù)的ID按照Hash取模分段，不同線程處理不同段數(shù)據(jù)。
• CAS算法：Java的Atomic包使用CAS算法來(lái)更新數(shù)據(jù)，而不需加鎖。
• 使用最少線程：避免創(chuàng)建不需要的線程。
• 協(xié)程：在單線程里實(shí)現(xiàn)多任務(wù)的調(diào)度，維持多任務(wù)間的切換。

9、操作系統(tǒng)進(jìn)程的調(diào)度策略

為了確定首先執(zhí)行哪個(gè)進(jìn)程以及最后執(zhí)行哪個(gè)進(jìn)程以實(shí)現(xiàn)最大 CPU 利用率，計(jì)算機(jī)科學(xué)家已經(jīng)定義了一些算法，它們是：

• 先到先服務(wù)(FCFS)調(diào)度算法 : 從就緒隊(duì)列中選擇一個(gè)最先進(jìn)入該隊(duì)列的進(jìn)程為之分配資源，使它立即執(zhí)行并一直執(zhí)行到完成或發(fā)生某事件而被阻塞放棄占用 CPU 時(shí)再重新調(diào)度。
• 短作業(yè)優(yōu)先(SJF)的調(diào)度算法 : 從就緒隊(duì)列中選出一個(gè)運(yùn)行時(shí)間最短的進(jìn)程為之分配資源，使它立即執(zhí)行并一直執(zhí)行到完成或發(fā)生某事件而被阻塞放棄占用 CPU 時(shí)再重新調(diào)度。
• 缺點(diǎn)：僅照顧了短進(jìn)程而忽略了長(zhǎng)進(jìn)程。
• 時(shí)間片輪轉(zhuǎn)調(diào)度算法 : 時(shí)間片輪轉(zhuǎn)調(diào)度是一種最古老，最簡(jiǎn)單，最公平且使用最廣的算法，又稱 RR(Round robin)調(diào)度。每個(gè)進(jìn)程被分配一個(gè)時(shí)間片，時(shí)間片用盡則退出對(duì)CPU資源的使用。
• 優(yōu)先級(jí)調(diào)度 ： 為每個(gè)進(jìn)程分配優(yōu)先級(jí)，首先執(zhí)行具有最高優(yōu)先級(jí)的進(jìn)程**，依此類推。**具有相同優(yōu)先級(jí)的進(jìn)程以 FCFS 方式執(zhí)行。可以根據(jù)內(nèi)存要求，時(shí)間要求或任何其他資源要求來(lái)確定優(yōu)先級(jí)。
• 存在的主要問題是：低優(yōu)先級(jí)進(jìn)程無(wú)窮等待CPU。
• 多級(jí)隊(duì)列調(diào)度算法：將就緒隊(duì)列分成多個(gè)獨(dú)立的隊(duì)列，每個(gè)隊(duì)列都有自己的調(diào)度算法，隊(duì)列之間采用固定優(yōu)先級(jí)搶占調(diào)度。其中，一個(gè)進(jìn)程根據(jù)自身屬性被永久、固定地分配到一個(gè)隊(duì)列中。
• 多級(jí)反饋隊(duì)列調(diào)度算法 ：目前被公認(rèn)的一種較好的進(jìn)程調(diào)度算法，UNIX 操作系統(tǒng)采取的便是這種調(diào)度算法。與多級(jí)隊(duì)列調(diào)度算法相比，其允許進(jìn)程在隊(duì)列之間移動(dòng)：若進(jìn)程使用過多CPU時(shí)間，那么它會(huì)被轉(zhuǎn)移到優(yōu)先級(jí)更低的隊(duì)列；在較低優(yōu)先級(jí)隊(duì)列等待時(shí)間過長(zhǎng)的進(jìn)程會(huì)被轉(zhuǎn)移到更高優(yōu)先級(jí)隊(duì)列，以防止饑餓發(fā)生。

10、什么是虛擬內(nèi)存？

虛擬內(nèi)存允許執(zhí)行任務(wù)的進(jìn)程不必完全在內(nèi)存中。很多時(shí)候我們使用點(diǎn)開了很多占內(nèi)存的軟件，這些軟件占用的內(nèi)存可能已經(jīng)遠(yuǎn)遠(yuǎn)超出了我們電腦本身具有的物理內(nèi)存。 正是因?yàn)?虛擬內(nèi)存 的存在，通過 虛擬內(nèi)存 可以讓程序可以擁有超過系統(tǒng)物理內(nèi)存大小的可用內(nèi)存空間（把內(nèi)存擴(kuò)展到硬盤空間）。

虛擬內(nèi)存的基本思想：

• 每個(gè)進(jìn)程擁有獨(dú)立的地址空間，這個(gè)空間被分為大小相等的多個(gè)塊，稱為頁(yè)(Page)，每個(gè)頁(yè)都是一段連續(xù)的地址。
• 這些頁(yè)被映射到物理內(nèi)存，但并不是所有的頁(yè)都必須在內(nèi)存中才能運(yùn)行程序。
• 當(dāng)程序引用到一部分在物理內(nèi)存中的地址空間時(shí)，由硬件立刻進(jìn)行必要的映射。
• 當(dāng)程序引用到一部分不在物理內(nèi)存中的地址空間時(shí)，由操作系統(tǒng)負(fù)責(zé)將缺失的部分裝入物理內(nèi)存并重新執(zhí)行失敗的命令。
• 這樣，對(duì)于進(jìn)程而言，邏輯上似乎有很大的內(nèi)存空間，實(shí)際上其中一部分對(duì)應(yīng)物理內(nèi)存上的一塊(稱為幀，通常頁(yè)和幀大小相等)，還有一些沒加載在內(nèi)存中的對(duì)應(yīng)在硬盤上

注意：

1、請(qǐng)求分頁(yè)系統(tǒng)、請(qǐng)求分段系統(tǒng)和請(qǐng)求段頁(yè)式系統(tǒng)都是針對(duì)虛擬內(nèi)存的，通過請(qǐng)求實(shí)現(xiàn)內(nèi)存與外存的信息置換。

2、如果虛擬內(nèi)存的頁(yè)并不存在于物理內(nèi)存中，會(huì)產(chǎn)生缺頁(yè)中斷，從磁盤中取得缺的頁(yè)放入內(nèi)存，如果內(nèi)存已滿，還會(huì)根據(jù)某種算法將磁盤中的頁(yè)換出。

頁(yè)面置換算法：

當(dāng)發(fā)生缺頁(yè)中斷時(shí)，如果當(dāng)前內(nèi)存中并沒有空閑的頁(yè)面，操作系統(tǒng)就必須在內(nèi)存選擇一個(gè)頁(yè)面將其移出內(nèi)存，以便為即將調(diào)入的頁(yè)面讓出空間。用來(lái)選擇淘汰哪一頁(yè)的規(guī)則叫做頁(yè)面置換算法，我們可以把頁(yè)面置換算法看成是淘汰頁(yè)面的規(guī)則。

• OPT 頁(yè)面置換算法（最佳頁(yè)面置換算法） ：最佳(Optimal, OPT)置換算法所選擇的被淘汰頁(yè)面將是以后永不使用的，或者是在最長(zhǎng)時(shí)間內(nèi)不再被訪問的頁(yè)面,這樣可以保證獲得最低的缺頁(yè)率。但由于人們目前無(wú)法預(yù)知進(jìn)程在內(nèi)存下的若千頁(yè)面中哪個(gè)是未來(lái)最長(zhǎng)時(shí)間內(nèi)不再被訪問的，因而該算法無(wú)法實(shí)現(xiàn)。一般作為衡量其他置換算法的方法。
• FIFO（First In First Out） 頁(yè)面置換算法（先進(jìn)先出頁(yè)面置換算法） : 總是淘汰最先進(jìn)入內(nèi)存的頁(yè)面，即選擇在內(nèi)存中駐留時(shí)間最久的頁(yè)面進(jìn)行淘汰。
• LRU （Least Currently Used）頁(yè)面置換算法（最近最久未使用頁(yè)面置換算法） ：LRU算法賦予每個(gè)頁(yè)面一個(gè)訪問字段，用來(lái)記錄一個(gè)頁(yè)面自上次被訪問以來(lái)所經(jīng)歷的時(shí)間 T，當(dāng)須淘汰一個(gè)頁(yè)面時(shí)，選擇現(xiàn)有頁(yè)面中其 T 值最大的，即最近最久未使用的頁(yè)面予以淘汰。
• LFU （Least Frequently Used）頁(yè)面置換算法（最少使用頁(yè)面置換算法） : 該置換算法選擇在之前時(shí)期使用次數(shù)最少的頁(yè)面作為淘汰頁(yè)。

虛擬內(nèi)存的應(yīng)用與優(yōu)點(diǎn)：

適合多道程序設(shè)計(jì)系統(tǒng)，許多程序的片段同時(shí)保存在內(nèi)存中。

當(dāng)一個(gè)程序等待它的一部分讀入內(nèi)存時(shí)，可以把CPU交給另一個(gè)進(jìn)程使用。

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

1、在內(nèi)存中可以保留多個(gè)進(jìn)程，系統(tǒng)并發(fā)度提高。 2、解除了用戶與內(nèi)存之間的緊密約束，進(jìn)程可以比內(nèi)存的全部空間還大。

局部性原理：

(1) 時(shí)間上的局部性：最近被訪問的頁(yè)在不久的將來(lái)還會(huì)被訪問。

(2) 空間上的局部性：內(nèi)存中被訪問的頁(yè)周圍的頁(yè)也很可能被訪問。

總結(jié)

本篇文章就到這里了，希望可以給你帶來(lái)一些幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容！

最新評(píng)論