摘自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代表把标准输出重定向到标准错误。