引言

其實IO操作相較于服務(wù)端，客戶端做的并不多，基本的場景就是讀寫文件的時候會使用到InputStream或者OutputStream，然而客戶端能做的就是發(fā)起一個讀寫的指令，真正的操作是內(nèi)核層通過ioctl指令執(zhí)行讀寫操作，因為每次的IO操作都涉及到了線程的操作，因此會有性能上的損耗，那么從本篇文章開始，我們將進入IO的世界，了解IO到NIO機制的演進，從底層關(guān)注序列化的原理。

1 Basic IO模型

那么在Java（Kotlin）中，IO主要分為兩種：Basic IO 和 Net IO；Basic IO是我們在開發(fā)當中常用的一些IO流，例如：

FileInputStream：//文件輸入流
FileOutputStream：//文件輸出流
BufferedInputStream：//緩存字節(jié)輸入流
BufferedOutputStream：//緩存字節(jié)輸入流，此類數(shù)據(jù)流為了提高讀寫效率，可以緩存數(shù)據(jù)到buffer，通過flush一起寫入；內(nèi)核分配內(nèi)存為一頁4K，但是Java緩沖區(qū)默認是8K
ObjectInputStream
ObjectOutputStream：// 將數(shù)據(jù)序列化處理
RandomAccessFile：//提供位移數(shù)據(jù)插入

對于前面的幾個數(shù)據(jù)流，我就不介紹用法了，對于最后一個RandomAccessFile，我想簡單介紹一下，因為很多伙伴們可能不知道RandomAccessFile的存在，這里曾經(jīng)有個面試題：

假設(shè)有一個5G的文件，我想在文章的末尾追加一段話，我該怎么處理？或者我指定任意位置添加一部分文字內(nèi)容，該怎么處理？

很多伙伴看到這個問題之后，一拍腦門說：先通過FileInputStream把文件讀寫進來，然后再在末尾追加一部分內(nèi)容組合成新的字節(jié)流，然后再通過FileOutputStream寫入到新的文件中。

完蛋，直接pass掉！因為前提這里已經(jīng)是5G的文件了，如果通過FileInputStream讀寫，大概率就會直接OOM! 所以如果知道RandomAccessFile的存在，這些就不是問題了。

fun testAccessFile() {
    //file文件
    val file = File("/storage/emulated/0/NewTextFile.txt")
    val accessFile = RandomAccessFile(file, "rw")
    //先寫一段
    val text = "IO主要分為兩種：Basic IO 和 Net IO；"
    accessFile.write(text.toByteArray())
    //再等5s
    Thread.sleep(5000)
    accessFile.seek(5)
    accessFile.write("seek to pos 5".toByteArray())
    accessFile.close()
}

首先我們常見一個RandomAccessFile，傳入要讀寫的文件，首先寫入一段話，然后等到5s后，調(diào)用RandomAccessFile的seek方法，此時指針就是移動到了文件第五個字符的位置，然后又寫入了一些文字。

所以按照這種思想，回到前面的問題，即便是5G的文件，也不需要進行讀寫操作獲取之前的全部數(shù)據(jù)就能夠?qū)崿F(xiàn)零內(nèi)存追加；當然還有一個場景也會經(jīng)常用到，就是斷點續(xù)傳。

1.1 RandomAccessFile的緩沖區(qū)和BufferedInputStream緩沖區(qū)的區(qū)別

首先我先簡單介紹下BufferedInputStream的緩存區(qū)效果，系統(tǒng)內(nèi)核緩存區(qū)默認為4K，當緩存區(qū)滿4K之后會進行磁盤的寫入；那么在Java中是對其做了優(yōu)化處理，將緩存區(qū)變?yōu)?K，當緩存區(qū)超過8K之后，會將數(shù)據(jù)復制給到內(nèi)核緩存。

fun testBuffer() {
        val file = File("/storage/emulated/0/NewTextFile.txt")
        val bis = BufferedOutputStream(FileOutputStream(file))
        val text = "8888888888888888".toByteArray()
        bis.write(text, 0, text.size)
//        bis.flush()
    }

例如上面的案例，此時App的內(nèi)存緩存區(qū)沒有滿，那么如果不調(diào)用flush，那么數(shù)據(jù)不會寫到磁盤文件中，只有當緩沖區(qū)滿了之后，才會復制到內(nèi)核空間緩存區(qū)。

fun testAccessFile() {
    //file文件
    val file = File("/storage/emulated/0/NewTextFile.txt")
    val accessFile = RandomAccessFile(file, "rw")
    //先寫一段
    val text = "IO主要分為兩種：Basic IO 和 Net IO；"
    accessFile.write(text.toByteArray())
    //再等5s
    Thread.sleep(5000)
    accessFile.seek(5)
    val channel = accessFile.channel
    val mapper = channel.map(FileChannel.MapMode.READ_WRITE, channel.position(), channel.size())
    mapper.put("seek to pos 5".toByteArray())
}

如果按照BufferedOutputStream的思想，我們往緩沖區(qū)寫數(shù)據(jù)，沒有flush就不會有復制的操作，那么我們實際看到的是數(shù)據(jù)還是寫進去了。

其實MappedByteBuffer，是提供了一個類似于mmap性質(zhì)的能力，實現(xiàn)了App緩沖區(qū)與內(nèi)核緩沖區(qū)的橋接或者映射。

當App寫入緩存數(shù)據(jù)的時候，直接映射到了內(nèi)核緩存區(qū)，完成了磁盤的讀寫操作。

1.2 Basic IO模型底層原理

其實對于基礎(chǔ)的IO模型，也就是Basic IO的實現(xiàn)是阻塞的，其實我們也可以自己驗證，在主線程中進行讀寫操作就是阻塞的。

那么對于IO來說，主要分為兩個階段：

（1）數(shù)據(jù)準備階段；這里是由Java實現(xiàn)的，寫入到JVM中；

（2）復制階段；內(nèi)核空間復制用戶空間緩存數(shù)據(jù)，這部分需要調(diào)用內(nèi)核函數(shù)（ioctl、sync），完成復制的工作。

剩下的磁盤寫入操作就完全是由內(nèi)核完成的，如果對于讀寫操作有疑問的，可以去看看下面這篇對于Binder底層原理的介紹。

Android Framework原理 -- Binder驅(qū)動源碼分析

對于傳統(tǒng)的Socket來說，這種屬于Net IO，本質(zhì)也是阻塞性質(zhì)的，例如App進程想要獲取一些數(shù)據(jù)，

上圖展示了read操作的整個調(diào)度過程：

（1）當App調(diào)用系統(tǒng)方法想要獲取某些數(shù)據(jù)的時候，首先系統(tǒng)內(nèi)核會等待數(shù)據(jù)從網(wǎng)絡(luò)中到達，這個過程內(nèi)核處于阻塞的狀態(tài)；

（2）等到數(shù)據(jù)到達之后，就會將網(wǎng)絡(luò)數(shù)據(jù)復制到用戶空間的緩沖區(qū)中，并通知App進程復制數(shù)據(jù)成功，此時App中其他業(yè)務(wù)才能夠繼續(xù)執(zhí)行。

所以整個過程中，App處于阻塞狀態(tài)，而在高并發(fā)的場景中（客戶端很少，這里拿服務(wù)端來舉例），例如10000QPS（每秒10000次查詢操作），此時如果采用IO阻塞模型，帶來的后果就是CPU極速拉滿最終可能導致熔斷，所以針對這種情況，出現(xiàn)了NIO模型。

2 NIO模型

相對于IO模型來說，NIO模型做的優(yōu)化是通過輪詢機制獲取內(nèi)核的數(shù)據(jù)等待狀態(tài)，看下圖：

當一次詢問發(fā)出之后，如果當前內(nèi)核還是數(shù)據(jù)等待狀態(tài)，那么內(nèi)核空間會被”掛起“，此時App進程可以做其他的事情，等到下一次輪詢時間到了之后，再次發(fā)起詢問，如果此時已經(jīng)拿到了數(shù)據(jù)，那么就會進行復制操作，將數(shù)據(jù)放入用戶進程緩沖區(qū)。

那么對此，java.nio包下提供了很多非阻塞IO的API，例如我們前面提到的MappedByteBuffer。其實還是前面我們探討的一個問題，在Android的場景下，很難碰到高并發(fā)的場景，所以基本上也很難用到這個，但是對于NIO模型的原理我們需要掌握透徹，在面試中可能會涉及到這些問題。

3 OKIO

最后介紹一個IO模型---OKIO，如果使用到OkHttp的伙伴們應(yīng)該已經(jīng)見到過這個，但是沒有實際地去研究，為啥要引入這個okio三方庫。

首先okio是OkHttp團隊基于Basic IO研發(fā)的一套自己的IO體系，為啥要搞一個這個玩意出來呢？通過前面我們分析Basic IO存在的一些問題，首先 Basic IO是阻塞的，而且在客戶端端如果頻繁地進行網(wǎng)絡(luò)請求，而且網(wǎng)絡(luò)請求是雙向的，從客戶端發(fā)出請求，服務(wù)端返回響應(yīng)，那么這個過程必定會使用到InputStream和OutputStream。

因為OkHttp是有自己的緩存策略的，如果使用到緩存，那么對于InputStream就需要一個buffer，對于OutputStream也需要一個buffer，每次讀寫操作都需要兩個buffer來做支撐，因此針對這種場景，okio在底層做了處理。

具體的處理就是不再使用byte[]數(shù)組存儲數(shù)據(jù)，而是采用Segment數(shù)據(jù)結(jié)構(gòu)。有熟悉Segment的伙伴應(yīng)該知道，它是一個數(shù)組的雙向鏈表，其中data就是一個byte數(shù)組，其中有next和pre兩個指針。

internal class Segment {
  @JvmField val data: ByteArray
  /** The next byte of application data byte to read in this segment.  */
  @JvmField var pos: Int = 0
  /** The first byte of available data ready to be written to.  */
  @JvmField var limit: Int = 0
  /** True if other segments or byte strings use the same byte array.  */
  @JvmField var shared: Boolean = false
  /** True if this segment owns the byte array and can append to it, extending `limit`.  */
  @JvmField var owner: Boolean = false
  /** Next segment in a linked or circularly-linked list.  */
  @JvmField var next: Segment? = null
  /** Previous segment in a circularly-linked list.  */
  @JvmField var prev: Segment? = null

當進行讀寫操作的時候，都會往Segment中寫入，就是將InputStream和OutputStream需要創(chuàng)建的緩沖區(qū)合并。

這里需要說明一點，okio屬于OkHttp內(nèi)部核心IO框架，并不是單獨拿出來任意業(yè)務(wù)方可以使用，所以對于okio的具體實現(xiàn)原理，后續(xù)會放在OkHttp框架原理中做詳細的介紹。

以上就是Android進階之從IO到NIO的模型機制演進的詳細內(nèi)容，更多關(guān)于Android模型從IO到NIO機制的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論