摘自http://zh.wikipedia.org/zh-cn/%E5%9B%BD%E9%99%85%E7%94%B5%E8%AF%9D%E5%8C%BA%E5%8F%B7%E5%88%97%E8%A1%A8
这里是一张全球国际电话服务的区号列表。所有的区号都是根据国际电信联盟（ITU）的E.123和E.164标准所分配的。所有的号码都是前缀号，也就是说这些号码是用来“拨到”目的国家的。每一个国家还有一个前缀来“拨出”自所处的国家，这个前缀叫国际冠码。简言之，国际冠码就是下列国际电话区号前的“+”前缀[1]。因此拨打国际电话的一般顺序是：国际冠码-国际电话区号-封闭电话号码；或者：国际冠码-国际电话区号-国内电话区号-开放电话号码。
目录
[code]
区域0 -- 保留
区域1 -- 北美洲
区域2 -- 非洲
区域3 -- 欧洲
区域4 -- 欧洲
区域5 -- 墨西哥及中南美洲
区域6 -- 东南亚及大洋洲
区域7 - 俄罗斯及附近地区 (前苏联)
区域8 -- 东亚及特殊服务
区域9 - 西亚及南亚、中东
[/code]
用IDE直接把源码生成可执行文件，这个过程叫构建（Build）。
实际上需要分四个步骤：预处理、编译、汇编、链接。
一、预处理。也叫预编译，编译之前的一个步骤。
先把用的示例代码列一下，输出比hello world更简单的：ok.c
[code]
#include <stdio.h>
int main(){
printf("OK!\n");
return 0;
}
[/code]
预编译指令：
[code]
gcc -E ok.c -o ok.i
[/code]
预处理的结果有16K多，非常长，内容我就不贴了。
1、CPU的分配方式（多道程序、分时系统、多任务系统）之间的区别。
多道程序是CPU闲时启动别的程序，简单来说：程序不用CPU时，被调用程序分配给别人。
分时系统是每个程序一段时间主动让出CPU，给别的程序用。全靠自觉。
多任务系统给每个程序分配指定的时间片，过期后强制程序让出CPU。被动的统一调配。
2、多任务系统运行在受硬件保护的级别，这个硬件指的是什么
目前我能想到的，就是内存分配。MMC是内存访问时的硬件限制机制。可能还有别的。
3、硬盘空间分配时，最小分配单位是扇区。硬盘现在一般用的是逻辑扇区号，硬盘内部的电子设备会自动转成物理的。
扇区是磁盘的最小可寻址单元（不是分配）。最小可分配单元是操作系统决定的，在windows系统里叫簇（clust），Linux中叫块（block），大小是扇区大小的2^n倍。
这里面有个问题，只要申请磁盘空间，哪怕是只有一个字节，也会分配一个块大小（比如：1024字节），有1023个字节无法再分配（浪费掉了）。
另外：windows中磁盘格式化的时候，可以选择“分配单元大小”，就是传说中的簇。
Linux中查看指定磁盘的块大小，可用
[code]
/sbin/tune2fs -l /dev/sda1
[/code]
查看Linux系统默认的块大小可用
[code]
getconf PAGESIZE
[/code]
有童鞋分享了unix的五种io模型，留意到里面有一句话“将数据从内核拷贝到用户空间”，怀疑这句话有问题。
unix的五种io模型中，把io读操作分为两个部分：
1、等待数据。
2、将数据从内核拷贝到用户空间。
我以java语言中的实现为例子：
在第三种模型“多路复用”中，第二步的数据读取工作可以是这样的
[code]
SocketChannel socketChannel = (SocketChannel) key.channel();
ByteBuffer dst = ByteBuffer.allocateDirect(1024);//分配的是直接内存
socketChannel.read(dst);
[/code]
数据直接从channel中读取到直接内存，没有从内核空间向用户空间拷贝的过程。
在第五种模型“aio”中，向aio_read函数中传递的缓冲区指针可以是mmap映射出的内存地址，也是内核到内核，没有内核空间向用户空间拷贝的问题。
当然，也可能是我理解有误，欢迎指正~
对mmap的读性能和原生的RandomAccessFile的读性能做了一下对比，从时间上比较，耗时不足之前的400分之一。
直接读536870910大小的物理文件，耗时199532毫秒。
mmap之后，再按再同的频度读相同的数据，耗时484毫秒。
本以为在SSD下测试，RandomAccessFile的性能会好很多，跟mmap方式的差距也会减少，在windows的系统上实测结果大跌眼镜：
等了十分钟，位于SSD磁盘的半个G文件没读完。次数降两个数量级，即512M/100次，得到结果如下
[code]
直接读536870910/100大小的物理文件，耗时10499毫秒。
0: 读(77767859:9)=9(和:2415919095, 耗时:578ms)
1: 读(387167008:8)=8(和:2415919095, 耗时:562ms)
2: 读(457186802:2)=2(和:2415919095, 耗时:546ms)
3: 读(394128468:8)=8(和:2415919095, 耗时:530ms)
[/code]
SSD下的磁盘读比mmap后相差了1816倍，远低于在Linux服务器上的测试结果。
在Windows开发机的普通磁盘上测试结果，磁盘性能略好于SSD
[code]
直接读536870910大小的物理文件，耗时9923毫秒。
0: 读(177389691:1)=1(和:2415919095, 耗时:562ms)
1: 读(390411737:7)=7(和:2415919095, 耗时:578ms)
[/code]
备注一下测试过程和中间的内存和CPU的表现。
用strace和perf的时候，直接把标准输出重定向到文件，发现无效。
把标准错误输出重定向到文件，才有效果。
比较奇怪，为什么strace和perf要把自己的输出用标准错误，而不是标准输出。
备忘一下重定向输出几个点
>覆盖式重定向。
>>追加式重定向。
1>代表重定向标准输出，1可以省略。
2>代表重定向标准错误。
1>&2代表把标准输出重定向到标准错误。