Golang 并发的一些我自己才看得懂的总结
Goroutine 是绿色线程，下面自带调度器。可以在 syscall 进入阻塞状态的时候自动出让 CPU（类似 Java 在进入锁以前自动引入自旋，这实际上是一种抢占式调度—preemptive scheduling），也可以通过runtime.Gosched()主动出让 CPU，调度器还可能无缘由地主动抢占 Goroutine 的时间片（比如已经运行了10ms）。因为是绿色线程，所以可以很便宜地创造百万Goroutine。在 Go 1.5 以后，可以通过 GOMAXPROCS 来使用更多的逻辑 CPU（而不也是系统进程）来利用多核。主线程不是主线程，主线程也是一个 main goroutine。
Go 关键字基本就等同于 Java 中提交一个 Runnable 到 CompletableFuture 的 CommonPool。在没有 Channel 的帮助时，goroutine 几乎可以等同于一个绿色的守护线程。
Go 也是有 mutex 的，但是不提倡使用，用 channel 最好。 share memory by communicating。
channel 是通过描述若干操 ...
Vim cheatsheet
比较好用的两个 vim 寄存器代码：
1234567#删除全部内容:%d# 在 vim 下，拷贝全部的代码:%y+# 在 mac 的 vim 下，拷贝全部的代码:%w !pbcopy
保险电销与互联网保险
保险电销的发迹史
电销在早期国内的常见渠道方式零售-求职-电视购物-保险-房地产-理财-催收-教育
人才从一个行业去到另一个行业。保险电销卖的保险业都在慢慢变化。
保险电销的发展历程
电销鼻祖—中美大都会人寿04年。先收集用户信息，然后再卖保险。
真正符合国际发展主流的电销—招商信诺。佣金模式很重要。
国内的保险电销为何逐步衰落。保险电销两三年后，坐席两三万很容易。职业瓶颈也出现了。
保险电销核心竞争力。
保险电销的流程
开场（黄金三十秒）
产品介绍
激发需求
核保
促成
成交确认
保险销售的套路
为客户创造需求。
如何激发你的保险需求。
如何未曾谋面判断你的财务状况。
如何让你冲动消费。
保险电销目前的机遇
结合互联网提升效率（互联网+电销）
健康险需求已经被激发，互联网模式有待考究，需要电销介入。
车险电销需要改变（系统智能化）。
由人海战术转变精英战术。
保险的逻辑
风险转移-保险可以解决风险的不确定性。愿意用确定的金额来为不确定性的风险买单。
保险的机制是独特的经济补偿机制。
有杠杆。
法律保护保险金。
保险资金投融资作用。
保险促进产业链整合。
商业问题解决。
...
系统调用为什么昂贵
系统调用的过程 系统有些高特权的操作，比如访问 IO 设备，修改内核状态，修改其他程序，在rings模型下，只有rings 0才能做得到。用户程序(通常是ring3)在自己的地址空间里面，是没有办法看到这些资源，也就无法修改它们。这时候用户程序就需要request service，发出软（件）中断，让程序trapped 进内核态(通过int 0x80 指令，实际上这不仅仅是进程的状态转换，也是进程的状态转换)。实际上此时的控制权已经交给内核了，内核可以在自己的内核地址空间里面，使用高特权操作，特权操作做完了以后，控制权才交回给用户程序。这个过程就成为syscall。x86 虽然有四层 ring，但通常只使用了0和3层ring。
系统通常提供API或者lib来提供syscall的能力。比如在 Unix-Like系统里，就是glibc。lib提供的函数，通常被称为Wrapper Function。
系统调用的代价在哪里 每次产生系统调用，程序的上下文通常会产生切换，CPU必然是要把进程状态寄存器里面往内存里塞，再 ...
单核上的多线程-Python中的 GIL
GIL （Global Interpreter Lock）的存在虽然无法利用多核，但是可以勉强让系统在在单核上，任何一个线程使用过多时间片/主动放弃 CPU 的时候，让其他线程上下文切入进来。算是尽量跑满CPU吧。Python中的对象很多都是默认线程安全的，GIL的这种不可见的特性，让很多旧的程序依赖起 GIL，以至于无法从Python中移除掉它。GIL 的存在，让 Python 特别适合跑 Nodejs 爬虫一样的 IO 密集型（IO-bound）任务，反而不适合跑CPU 密集型任务（CPU-bound）。但实际上这种混蛋多线程的形式，恐怕还不如 EventLoop 的 Nodejs，因为多了很多 Context Switch 的代价。
面向对象范式的历史
面向对象，聚讼纷纷。
Java中的幽灵类型
先上结论：幽灵类型（Phantom Type）是一种可以把有些运行时才能检测到的错误，在编译时检测出来的技巧。按照有些老外的观点，就是“Making Wrong Code Look Wrong”。在面向对象的编程语言之中，幽灵类型的实现，往往与状态模式较为接近，但比状态模式提供了更强的纠错功能。在Java 5 以后的版本里，程序员可以使用泛型。通过泛型的类型参数，Java 中也拥有了幽灵类型的能力。
上面的阐述是不是很难看懂？我也觉得拗口，让我们直接进入具体的例子。假设我们要写一个飞机控制程序，操作飞机起飞或者落地。这个程序有一个非常强的业务约束，就是必须保证飞机一开始必须出现在的地上，只有在地上的飞机可以起飞，只有起飞的飞机可以落地，那么我们应该怎样设计我们的程序（主要是类型关系），来保证这个约束必然成立呢？
让我们先来定义一组状态接口:
123456789101112131415161718192021/** * FlightStatus.java * @author liangchuan */public i ...
一段改写的超级账本的链码
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174/* * 改编自 IBM 的源码示例。 */package mainimport ( "bytes" "fmt" ...
OOM Killer
Linux 内核有个 OOM Killer 的机制，可以在系统内存不足的时候，通过主动杀死一些进程来释放更多的内存空间。
很多时候，我们可以 ping 通一台服务器，但无法 ssh 上去，因为 sshd 被 OOM Killer 杀掉了。ping 能 ping 通，是因为处在内核态协议栈还能工作，发出回送报文。sshd 则因为是用户态进程，直接被干掉了。
关闭再打开 OOM Killer 的方法：
12echo "0" > /proc/sys/vm/oom-killecho "1″ > /proc/sys/vm/oom-kill
OOM Killer 决定是否要杀死一个进程，主要看两个指标：
/proc/PID/oom_score 的分数
/proc/PID/oom_adj
可以通过以下方法强制内核不得杀死某个进程：
1pgrep -f "/usr/sbin/sshd" | while read P ...
支付业务
支付牌照是金融体系里唯一还在卖的交易拍照。
金融业务分为三大类：银行、保险、证券。
银行业分为表内和表外的业务。支付是银行业的一部分。
是不是计入资产负债表—表内、表外业务。
表外业务是银行的服务业务，毛利高。
支付是表外业务。
互联网三大赚钱业务（变现场景对应支付的三个工具）：
游戏（支付工具）。
广告（大数据量级几张）。
互联网金融（电子账户和实名认证）。把银行账户体系电子化了。
货币最终是由国家发行的，铸币权是国家权力的体现。后来出现电子化货币，简化了票据类银行业务。
支付基础概念 电子支付是在付款银行和收款银行之间的货币债权转移。
支付体系的构成—基于银行卡体系的四方模式：
发卡方（服务商户，提供银行卡/二维码）
商户
收单方（服务商户。老式的 pos 机是要拓片留印记的。pos 机/摄像头）
清算方（卡组的清算机构，国内是银联，国外就是 ...
