minor GC不会对phantom reference和soft reference进行收集，只有full GC才会。这样的问题就是大量的这类对象积聚起来，产生许多的内存复制。

这样每次minor GC可能就基本上没有释放多少内存，使得full GC就会被频繁触发。可能出现minor GC和full GC次数1：1的情况，甚至全是full GC。

这样，无论是性能还是可扩展性都是非常差的。

在JNI开发中，使用这3种reference的主要目的是保证native资源的释放。因为java对象的finalize方法是不保证被调用的，所以必须用这些

memory中的开销。

线程安全和线程模型
 

这个是Muxd一直用的东西
相当于一个双向PIPE
Process A open ptm得到fdm，然后fork出process B，process B open pts得到fds，然后将0,1,2都dup到fds上
那么fds就变成了process B的控制终端
后面再process B中做标准IO操作的时候就会像PIPE直接影响到fdm
终端行规程在pts之上

没什么特别要记录的，在网上search了下，贴个链接，里面会介绍一些基本概念.
http://www.cnblogs.com/Anker/archive/2012/12/25/2832568.html

终端行规程 terminal line discipline
会帮忙做规范处理

终端设备属性 ->termios

struct termios {
 tcflag_t c_iflag;
 tcflag_t c_oflag;
 tcflag_t c_cflag;
 tcflag_t c_lflag;
 cc_t c_line;
 cc_t c_cc[NCCS];
};

local flag影响驱动程序和用户之间的接口
Android上tcflag_t->
typedef unsigned int tcflag_t;

cc_t
typedef unsigned char cc_t;

control flag中很多选项标志都是用几位标识然后用或来做选择

isatty的实现，借助tcgetattr的出错机制，成功返回0；否则返回-1，带上ENOTTY

int
isatty (int  fd)
{
  struct termios term;

  return tcgetattr (fd, &term) == 0;
}

Anyway，终端IO很复杂...

创建两个PIPE，一个用于输入给协同进程，另外一个用于接收协同进程的输出
fork之后在子进程中将标准输入输出都dup到管道上

而协同进程的写法可以比较common，只用关心标准输入输出。
PIPE在写的时候如果有多个写进程，那么写的数据小于 PIPE_BUF 则不会乱序，否则自己应该就需要做同步了。

然后就是FIFO，这个就是用mkfifo创建一个file，大家都去用。
PIPE和FIFO都是半双工的

XSI IPC ->即之前System V IPC
消息队列 信号量 共享存储器

在无关进程之间共享存储段，一个是使用上面V系统shm；另外一个是使用mmap将同一文件map到他们自己的进程空间。

另外就是网络IPC了
算是复习下吧，之前这块儿看的比较多
int socket(int domain, int type, int protocol)
domain标识address family -> AF_INET, AF_INET6, AF_UNIX(AF_LOCAL), AF_UNSPEC
type标识socket类型 -> SOCK_DGRAM(UDP), SOCK_RAW(IP), SOCK_SEQPACKET, SOCK_STREAM(TCP)

一般protocol都设置为0，一般address family和type就能确认要使用的protocol

SOCK_SEQPACKET和SOCK）STREAM很像，前一个提供面向数据报文的服务，而后面这种则是面对流。
SOCK_SEQPACKET使用场景SCTP，贴一个SCTP的简要介绍。
http://www.cnblogs.com/qlee/archive/2011/07/13/2105717.html

涉及网络就必须要清楚字节序的问题，字节序与字符编码是两件不同的事情，都要想清楚的，但是要提一下UTF-8这是一种专门设计用来做网络传输的字符编码
无需关心字节序的问题，所以传输的上层数据可以用UTF-8，就不用担心local host和remote host的主机字节序不一样而导致乱序了。

但是很多协议头必须做符合TCP/IP协议的字节序规范，TCP/IP是big endian
关于Big endian和Litter endian我比较容易忘记具体的样子，但是他的出发点是低地址，低地址装的是最高有效字节那么就是big endian，否则就是litter endian。

关于socket有几个可能比较模糊的地方
connect时，也就是client端，如果fd没有绑定到某个地址，那么kernel会帮忙将其绑定到默认地址; 所以bind这件事情是Client和Server都需要做的事情，调用listen之前也一样
然后accept的时候，如果你关心对方的地址，那么提供addr(足够)和len，返回的时候就能知道。
另外UDP(SOCK_DGRAM)也可以Call connect，之后就可以直接call send/write，而不必每次都call sendto指定对端地址。

sendto中flag一般给0，如果是紧急数据给MSG_OOB

文件描述符的传输，目的是想让不同的process在不同的文件描述符中共享文件表。
所以做法上系统会这样，传输文件表指针然后放到接收端的第一个可用的文件描述符上。
这个我在linux上没找到实现，因为这个功能还是有蛮多替代方案的。

低速系统调用，也就是有信号发生会返回 errno 为 EINTR的

磁盘文件IO虽然有延时，但是这个不能算是低速系统调用

APUE介绍的低速系统调用
PIPE，终端设备，网络设备 读写
读无数据/写无空间(例如TCP卡Congestion window)

打开某些特殊文件
加记录锁的文件读写
ioctl，IPC

文件锁又叫做 byte-range locking，针对特定的文件区域，适合数据库文件
Posix标准
int fcntl(int fd, int cmd, .../* struct flock* flockptr */)
cmd -> F_GETLK,F_SETLK,F_SETLKW
F_SETLKW是F_SETLK的Blocking版本 W means wait

重要数据结构是struct flock ->
struct flock {
 short l_type;
 short l_whence;
 off_t l_start;
 off_t l_len;
 pid_t l_pid;
 __ARCH_FLOCK_PAD
};

锁定整个file的方式: l_whence = SEEK_SET, l_start = 0, l_len = 0

l_type的两类lock
F_RDLCK，F_WRLCK这两种锁的特性很像rw lock

不过与读写锁不一样的是或者这样讲
Posix.1没有规定下面这种情况: process A在某文件区间上设置了一把读锁；process B尝试在这个文件区间加上写锁的时候suspend；process C再尝试获取读锁，如果允许

process C拿到读锁，那么process B将会可能永远拿不到写锁，活活饿死

pthread里面的rw lock的实现会在这种情况下suspend掉process C的读锁请求；但是目前文件区域锁的实现我不太确定

这里看文件区域锁还是比较容易带来deadlock的
例如process A锁住F1的某个区域，然后去锁F2的一个区域，这时候F2的这个区域被process B锁住，那么process A就会suspend，如果这个时候process B过来要锁F1的这个区域
就会发生deadlock

关于文件区域锁的继承和释放
1.fork后，文件区域锁并不继承，继承了就完了，不同的process就有可能同时干同一件事情，把数据搞坏
2.close(fd)后 fd对应的文件锁就被释放了，文件锁挂在inode上，close的时候kernel会去扫描对应的inode上与这个PID相关的lock，释放掉，而并不去关心是哪个文件描述符或

者是哪个文件表，这很重要，因为lockf中并不记录fd，他们只是弱关联关系，这个很重要。
3.exec后，文件锁会继承原来执行程序的锁(fork之后拿到的lock)，如果fd带有close-on-exec那么根据第二条，这个fd对应的file上的锁都会被释放。

后面讲了STREAMS，感觉linux上用到的不多，需要在编译kernel时动态加载

IO多路转接，主要是为了实现polling既所谓的轮询
主要函数有select，pselect，poll，epoll
select也会算是低速系统调用，那么就有可能被信号打断
pselect有参数可以设定信号屏蔽集，也提供更高精度的timer

poll的方式与select有不太一样的地方，但是功能相同，epoll更适合大数据量。

readv和writev
记住下面两条就够了
一个称为scatter read(散步读)；另外一个称为gather write(聚集写)
这两个函数会面对一个buffer链表。

readn和writen
这个比较像现在Android里面socket的read和write方式，保证能read/write n byte数据，在内部做循环
我比较好奇这两个是否会处理signal，想来应该是会处理的，遇到EINTR帮忙重启就好了

我没有找到Bionic库的实现

存储映射IO
这个很重要，mmap用的很多，映射到process空间的位置在 stack以下，heap以上的部分，map完后返回低地址。

#include<sys/mman.h>
void* mmap(void* addr, size_t len, int prot, int flag, int filedes, off_t off)

prot -> PROT_READ,PROT_WRITE,PROT_EXEC,PROT_NONE
prot指定的对映射存储区的保护不能超过文件的open权限

在 flag为 MAP_FIXED的时候OS会保证分配的memory起始地址为addr，否则只是给OS一个建议。
一般建议addr给0，让OS来决定。

MAP_SHARED是说对映射区域的存储(write)会导致修改该文件。
MAP_PRIVATE则是对映射区域的操作会常见一个映射文件的副本。

后面有个例子用了lseek
使用lseek增加文件长度的方式，先lseek一个值，如果这个值大于文件本身的长度，那么下一次写就会加长该文件，并且在文件
中形成一个空洞，未写过的内容全部读为0。
mmap只能map文件的最大长度，超过的地方没办法同步到文件。