- 什么是mmap mmap對於c程序員很熟悉，對於java程序員有點陌生。簡而言之，將文件直接映射到用戶態的內存地址，這樣對文件的操作不再是write/read,而是直接對內存地址的操作。
-
在c中提供了三個函數來實現
-
[list]
- mmap 進行映射
- munmap 取消映射
- msync 進程在映射空間的對共享內容的改變並不直接寫回到磁盤文件中，往往在調用munmap()后才執行該操作。
具體參照http://blog.chinaunix.net/uid-24517893-id-164217.html
- java中的map
java中的FileChannel，提供了map和force方法，map創建文件和內存的映射，
- MappedByteBuffer buffer = fc.map(MapMode.READ_WRITE, 0, 1000);
返回一個MappedByteBuffer，這是一個DirectBuffer，其中包含一個內存地址，然后可用就做一些讀寫操作。
還有另外一個方法是force，是將內存的更新的內容刷到磁盤中。
在這里拋出一個問題，force是必須調用的，如果不調用force會怎樣。
我試着寫了一段小程序來試驗
- MappedByteBuffer buffer = fc.map(MapMode.READ_WRITE, 0, 1000);
- for (int i = 0;i< 100000;i++){
- buffer.put((byte)65);
- }
- System.out.println("write completed!");
- System.in.read();
然后觀察文件發現文件中是有1000個B的，那么就是說不調用force，內容也會落到磁盤中的。既然不用force內容也可以落到磁盤中，那force的作用什么呢？帶着這個問題我查看了openJdk的force和map的實現和linux中mmap的實現。
- JDK的force和map的實現
通過FileChannel->FileChannelImpl的native知道，對linux平台調用應該在D:\git\openjdk\jdk\src\solaris\native\sun\nio\ch下的FileChannelImpl.c
- NIEXPORT jlong JNICALL
- Java_sun_nio_ch_FileChannelImpl_map0(JNIEnv *env, jobject this,
- jint prot, jlong off, jlong len)
- mapAddress = mmap64(
- 0, /* Let OS decide location */
- len, /* Number of bytes to map */
- protections, /* File permissions */
- flags, /* Changes are shared */
- fd, /* File descriptor of mapped file */
- off); /* Offset into file */
- JNIEXPORT jint JNICALL
- Java_sun_nio_ch_FileChannelImpl_force0(JNIEnv *env, jobject this,
- jobject fdo, jboolean md)
- {
- jint fd = fdval(env, fdo);
- int result = 0;
- if (md == JNI_FALSE) {
- result = fdatasync(fd);
- } else {
- result = fsync(fd);
- }
- return handle(env, result, "Force failed");
- }
原來force是調用的fdatasync(fsync)，這不是linux中buffered IO，write(2)以后需要調用的方法嗎，難道mmap也是走的BufferdIO那一套，首先寫到page cache，然后由pdflush定時刷到磁盤中，那這么說mmap只是在進程空間分配一個內存地址，真實的內存還是使用的pagecache。所以force是調用fsync將dirty page刷到磁盤中，但mmap還有共享之類的實現起來應該很復雜。
- 驗證
為了驗證上面的假設，我做了一個實驗。在linux下起兩個終端，A終端通過上面的程序向a.txt寫入數據，B終端使用tailf a.txt觀察數據的寫入。奇怪的是A終端執行完，B終端立馬就成看到數據，而不是等30s以后pdflush刷到磁盤以后才能看到，難道前面的假設錯了？或者另一種可能tailf查看到也是在page cache中讀取的。那只需查看下文件的page是不是dirty就知道了。
- cat /proc/$(pidof java)/smaps|grep a.txt -A 10 -B 10
就可以查看一個文件的page是否是dirty。
重新實現使用如上腳本觀察
- 2aaab30c4000-2aaab31b9000 rw-s 00000000 fd:00 81887299 /opt/zhanghailei/a.txt
- Size: 980 kB
- Rss: 980 kB
- Shared_Clean: 0 kB
- Shared_Dirty: 0 kB
- Private_Clean: 0 kB
- Private_Dirty: 980 kB
- Swap: 0 kB
- Pss: 980 kB
果然是dirty的，然后繼續等待一段時間再次執行發現已經是clean，被刷到磁盤中。
- 2aaab30c4000-2aaab31b9000 rw-s 00000000 fd:00 81887299 /opt/zhanghailei/a.txt
- Size: 980 kB
- Rss: 980 kB
- Shared_Clean: 0 kB
- Shared_Dirty: 0 kB
- Private_Clean: 980 kB
- Private_Dirty: 0 kB
- Swap: 0 kB
- Pss: 980 kB
- 結論
1. mmap，底層還是走的BufferedIO，好處大概是減少了內核態和用戶態的內存拷貝，這點不太確定，對內核不熟。
2. force，參數為true調用fsync，false調用fdatasync，fdatasync只刷數據不刷meta數據
3. 即使不調用force，內核也會定期將dirty page刷到磁盤，默認是30s。
原文來自：http://xiaoz5919.iteye.com/blog/2093323