在开始记录实践之前，建议先阅读一下两篇文章：
The Clean Architecture
Trying Clean Architecture on Golang

Clean Architecture基本概念

Each of these architectures produce systems that are:

1. Independent of Frameworks. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.
2. Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element.
3. Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
4. Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
5. Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world.

An attempt:

The Dependency Rule

Entities: 封装了企业维度的business rules. Entity可以是an object with methods, 或者是a set of data structures and functions. 如果是简单应用，entity则是应用的business objects。他们应该是最不可能随外部变化的。
Use Cases: 包含了application specific的business rules。封装并实施all the use cases of the system.这些use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.
Interface Adapters: 是a set of adapters用来把数据从use cases和entities层的格式转换到external agency(DB or web)。这个层会完整包含MVC结构。同样，这层会把从use cases和entities层的数据形式转换到持久层framework, 比方数据库。在此层往内的代码无需知道数据库。如果是SQL数据库，则所有SQL必须受到此层约束，尤其是和数据库相关的部分。
Frameworks & Drivers: 最外层一般由框架和工具组成，比方数据库，网络架构等。一般只放些与外界沟通的胶水代码。

Crossing boundaries

At the lower right of the diagram is an example of how we cross the circle boundaries. It shows the Controllers and Presenters communicating with the Use Cases in the next layer. Note the flow of control. It begins in the controller, moves through the use case, and then winds up executing in the presenter. Note also the source code dependencies. Each one of them points inwards towards the use cases.

We usually resolve this apparent contradiction by using the Dependency Inversion Principle. In a language like Java, for example, we would arrange interfaces and inheritance relationships such that the source code dependencies oppose the flow of control at just the right points across the boundary.

Dependency Inversion Principle
记得使用Dependency Inversion Principle，即：

1. High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces).
2. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
   In a language like Java, for example, we would arrange interfaces and inheritance relationships such that the source code dependencies oppose the flow of control at just the right points across the boundary.
   

For example, consider that the use case needs to call the presenter. However, this call must not be direct because that would violate The Dependency Rule: No name in an outer circle can be mentioned by an inner circle. So we have the use case call an interface (Shown here as Use Case Output Port) in the inner circle, and have the presenter in the outer circle implement it.

The same technique is used to cross all the boundaries in the architectures. We take advantage of dynamic polymorphism to create source code dependencies that oppose the flow of control so that we can conform to The Dependency Rule no matter what direction the flow of control is going in.

Golang中的对应

Entities-->Models: 存储对象结构与方法。Same as Entities, will used in all layer. This layer, will store any Object’s Struct and its method. Any entities, or model will stored here.
举例：

import "time"

type Article struct {
	ID        int64     `json:"id"`
	Title     string    `json:"title"`
	Content   string    `json:"content"`
	UpdatedAt time.Time `json:"updated_at"`
	CreatedAt time.Time `json:"created_at"`
}

Use Cases: 处理业务流程。This layer will act as the business process handler. Any process will handled here. This layer will decide, which repository layer will use. And have responsibility to provide data to serve into delivery. Process the data doing calculation or anything will done here.
Usecase layer will accept any input from Delivery layer, that already sanitized, then process the input could be storing into DB , or Fetching from DB ,etc.
This Usecase layer will depends to Repository Layer

Delivery: 扮演presenter，API接口等。This layer will act as the presenter. Decide how the data will presented. Could be as REST API, or HTML File, or gRPC whatever the delivery type.
This layer also will accept the input from user. Sanitize the input and sent it to Usecase layer.
For my sample project, I’m using REST API as the delivery method.
Client will call the resource endpoint over network, and the Delivery layer will get the input or request, and sent it to Usecase Layer.
This layer will depends to Usecase Layer.

Repository: 纯数据库操作。Repository will store any Database handler. Querying, or Creating/ Inserting into any database will stored here. This layer will act for CRUD to database only. No business process happen here. Only plain function to Database.
This layer also have responsibility to choose what DB will used in Application. Could be Mysql, MongoDB, MariaDB, Postgresql whatever, will decided here.
If using ORM, this layer will control the input, and give it directly to ORM services.
If calling microservices, will handled here. Create HTTP Request to other services, and sanitize the data. This layer, must fully act as a repository. Handle all data input - output no specific logic happen.
This Repository layer will depends to Connected DB , or other microservices if exists.

Communications Between Layers

Except Models, each layer will communicate through inteface. For example, Usecase layer need the Repository layer, so how they communicate? Repository will provide an interface to be their contract and communication.

References:
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
https://hackernoon.com/golang-clean-archithecture-efd6d7c43047
https://www.cnblogs.com/gaochundong/p/dependency_inversion_principle.html
https://www.jianshu.com/p/272dc047d527

常见的序列化方式有：
JDK（不支持跨语言）、JSON、XML、Hessian、Kryo（不支持跨语言）、Thrift、Protostuff、FST（不支持跨语言）

技术选型关键点：
协议是否支持跨平台，序列化的速度（时间开销，系统性能），序列化出来的大小（空间开销，减轻网络、磁盘压力）。

典型的序列化和反序列化过程往往需要如下组件：

• IDL（Interface description language）文件：参与通讯的各方需要对通讯的内容需要做相关的约定（Specifications）。为了建立一个与语言和平台无关的约定，这个约定需要采用与具体开发语言、平台无关的语言来进行描述。这种语言被称为接口描述语言（IDL），采用IDL撰写的协议约定称之为IDL文件。
• IDL Compiler：IDL文件中约定的内容为了在各语言和平台可见，需要有一个编译器，将IDL文件转换成各语言对应的动态库。
• Stub/Skeleton Lib：负责序列化和反序列化的工作代码。Stub是一段部署在分布式系统客户端的代码，一方面接收应用层的参数，并对其序列化后通过底层协议栈发送到服务端，另一方面接收服务端序列化后的结果数据，反序列化后交给客户端应用层；Skeleton部署在服务端，其功能与Stub相反，从传输层接收序列化参数，反序列化后交给服务端应用层，并将应用层的执行结果序列化后最终传送给客户端Stub。
• Client/Server：指的是应用层程序代码，他们面对的是IDL所生存的特定语言的class或struct。
• 底层协议栈和互联网：序列化之后的数据通过底层的传输层、网络层、链路层以及物理层协议转换成数字信号在互联网中传递。
  

序列化组件与数据库访问组件的对比
数据库访问对于很多工程师来说相对熟悉，所用到的组件也相对容易理解。下表类比了序列化过程中用到的部分组件和数据库访问组件的对应关系，以便于大家更好的把握序列化相关组件的概念。

References:
https://tech.meituan.com/2015/02/26/serialization-vs-deserialization.html

From Microsoft

DNS uses TCP for Zone transfer and UDP for name, and queries either regular (primary) or reverse. UDP can be used to exchange small information whereas TCP must be used to exchange information larger than 512 bytes. If a client doesn't get response from DNS, it must retransmit the data using TCP after 3-5 seconds of interval.

From Scoolor Blog

DNS在进行区域传输的时候使用TCP协议，其它时候则使用UDP协议

DNS的规范规定了2种类型的DNS服务器，一个叫主DNS服务器，一个叫辅助DNS服务器。在一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息，而辅助DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息。当一个辅助DNS服务器启动时，它需要与主DNS服务器通信，并加载数据信息，这就叫做区传送（zone transfer）。

区域传输是DNS的事务，对准确性要求比较高，而且会产生大于512字节的数据包，因此使用TCP协议。

为什么既使用TCP又使用UDP？

首先了解一下TCP与UDP传送字节的长度限制。

UDP报文的最大长度为512字节，而TCP则允许报文长度超过512字节。当DNS查询超过512字节时，协议的TC标志出现删除标志，这时则使用TCP发送。通常传统的UDP报文一般不会大于512字节。

区域传送时使用TCP，主要有一下两点考虑

辅域名服务器会定时（一般时3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用TCP而不是UDP，因为数据同步传送的数据量比一个请求和应答的数据量要多得多。
TCP是一种可靠的连接，保证了数据的准确性。

域名解析时使用UDP协议

客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过TCP三次握手，这样DNS服务器负载更低，响应更快。虽然从理论上说，客户端也可以指定向DNS服务器查询的时候使用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。

总结

大多数情况下，DNS解析请求和响应都很小，使用UDP协议更加高效，虽然没有TCP可靠，但是速度快，消耗的系统资源更少，非常适合少量数据包的传输。
一些DNS事务，比如区域传输或其他附加查询，可能会产生大于512字节的数据包，因此使用TCP更加可靠，使用TCP会减少丢包和重新发包的情况，因此更加可靠与高效。

References:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-works-on-tcp-and-udp
https://www.zhihu.com/question/310145373
https://scoolor.github.io/2018/11/10/dns-udp-tcp/

今天正巧看到了，先总结在这里

back_log

The number of outstanding connection requests MySQL can have. This comes into play when the main MySQL thread gets very many connection requests in a very short time. It then takes some time (although very little) for the main thread to check the connection and start a new thread. The back_log value indicates how many requests can be stacked during this short time before MySQL momentarily stops answering new requests. You need to increase this only if you expect a large number of connections in a short period of time.

In other words, this value is the size of the listen queue for incoming TCP/IP connections. Your operating system has its own limit on the size of this queue. The manual page for the Unix listen() system call should have more details. Check your OS documentation for the maximum value for this variable. back_log cannot be set higher than your operating system limit.

The default value is the value of max_connections, which enables the permitted backlog to adjust to the maximum permitted number of connections.

max_connections

The maximum permitted number of simultaneous client connections. The maximum effective value is the lesser of the effective value of open_files_limit - 810, and the value actually set for max_connections.

For more information, see Section 5.1.12.1, “Connection Interfaces”.

https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html
详解linux中的backlog

本文非纯原创，是各文杂糅而来加部分自身实践，在此致谢各位作者！

正文

说到硬链接（Hard link）与软链接(Symbolic link)，首先需要了解索引节点（Inode）。关于Inode请移步这里。

硬链接

由于linux下的文件是通过索引节点（Inode）来识别文件，硬链接可以认为是一个指针，指向文件索引节点的指针，系统并不为它重新分配inode。inode指向了物理硬盘的一个区块，事实上文件系统会维护一个引用计数，只要有文件指向这个区块，它就不会从硬盘上消失。每添加一个一个硬链接，文件的链接数就加1。

用ln命令来建立硬链接。

#用法
usage: ln [-Ffhinsv] source_file [target_file]
       ln [-Ffhinsv] source_file ... target_dir
       link source_file target_file

#创建前
➜  ~ ls -lrth tmp
-rw-r--r--  1 hanzhu  staff     0B Oct  9 20:41 tmp

#创建硬链接
➜  ~ ln tmp tmphard

#创建后
➜  ~ ls -ilrth tmp*
38351334 -rw-r--r--  2 hanzhu  staff     0B Oct  9 20:41 tmphard
38351334 -rw-r--r--  2 hanzhu  staff     0B Oct  9 20:41 tmp

注意在创建链接前, tmp显示的链接数目为1,创建链接后

1. tmp和tmphard的链接数目都变为2;
2. tmp和tmphard在inode号是一样的;
3. tmp和tmphard显示的文件大小也是一样。
   可见进行了ln命令的操作结果：tmp和tmphard是同一个文件的两个名字，它们具有同样的索引节点号和文件属性，建立文件tmp的硬链接，就是为tmp的文件索引节点在当前目录上建立一个新指针。

如下示例,你可以删除其中任何一个,比如rm tmp ,每次只会删除一个指针，链接数同时减一,只有将所有指向文件内容的指针,也即链接数减为0时，内核才会把文件内容从磁盘上删除。

#删除
➜  ~ rm tmp
➜  ~ ls -ilrth tmp*
38351334 -rw-r--r--  1 hanzhu  staff     0B Oct  9 20:41 tmphard

不足：
尽管硬链接节省空间，也是Linux系统整合文件系统的传统方式，但是存在以下不足之处：

1. 不可以在不同文件系统的文件间建立链接
2. 只有超级用户才可以为目录创建硬链接。

一些硬链接总结：

• 硬链接文件是普通文件，可以用rm删除；
• 具有相同inode节点号的多个文件互为硬链接文件；
• 删除硬链接文件或者删除源文件任意之一，文件实体并未被删除；
• 只有删除了源文件和所有对应的硬链接文件，文件实体才会被删除；
• 硬链接文件是文件的另一个入口；
• 可以通过给文件设置硬链接文件来防止重要文件被误删；
• 创建硬链接命令 ln 源文件 硬链接文件；
• 对于静态文件（没有进程正在调用），当硬链接数为0时文件就被删除。注意：如果有进程正在调用，则无法删除或者即使文件名被删除但空间不会释放。

软链接

软链接克服了硬链接的不足，没有任何文件系统的限制，任何用户可以创建指向目录的符号链接。因而现在更为广泛使用，它具有更大的灵活性，甚至可以跨越不同机器、不同网络对文件进行链接。软链接的inode所指向的内容实际上是保存了一个绝对路径，当用户访问这个文件时，系统会自动将其替换成其所指的文件路径。

如果给ln命令加上- s选项，则建立软链接。如果[链接名] 已经存在但不是目录，将不做链接。[链接名]可以是任何一个文件名（可包含路径），也可以是一个目录，并且允许它与“目标”不在同一个文件系统中。如果[链接名]是一个已经存在的目录，系统将在该目录下建立一个或多个与“目标”同名的文件，此新建的文件实际上是指向原“目标”的符号链接文件。

用ln -s命令来建立软链接。

#创建软链接
➜  ~ ln -s  tmp tmpsoft

#创建后
➜  ~ ls -ilrth tmp*
38351334 -rw-r--r--  2 hanzhu  staff     0B Oct  9 20:41 tmphard
38351334 -rw-r--r--  2 hanzhu  staff     0B Oct  9 20:41 tmp
38364003 lrwxr-xr-x  1 hanzhu  staff     3B Oct  9 21:58 tmpsoft -> tmp

软链接与硬链接，区别不仅仅是在概念上，在实现上也是不同的。区别：

1. 硬链接原文件＆链接文件公用一个inode号，说明他们是同一个文件，而软链接原文件＆链接文件拥有不同的inode号，表明他们是两个不同的文件；
2. 在文件属性上软链接明确写出了是链接文件，而硬链接没有写出来，因为在本质上硬链接文件和原文件是完全平等关系；链接数目是不一样的，软链接的链接数目不会增加；
3. 文件大小是不一样的，硬链接文件显示的大小是跟原文件是一样的，因为是等同的，而这里软链接显示的大小与原文件就不同了，tmp大小是0B，而tmpsoft是3B.

总之，建立软链接就是建立了一个新文件。当访问链接文件时，系统就会发现他是个链接文件，它读取链接文件找到真正要访问的文件。

缺点：

1. 因为链接文件包含有原文件的路径信息，所以当原文件从一个目录下移到其他目录中，再访问链接文件，系统就找不到了，而硬链接就没有这个缺陷，你想怎么移就怎么移；
2. 它要系统分配额外的空间用于建立新的索引节点和保存原文件的路径。

一些软链接总结：

• 软链接类似windows系统的快捷方式；
• 软链接里面存放的是源文件的路径，指向源文件；
• 删除源文件，软链接依然存在，但无法访问源文件内容；
• 软链接失效时一般是白字红底闪烁；
• 创建软链接命令 ln -s 源文件 软链接文件；
• 软链接和源文件是不同的文件，文件类型也不同，inode号也不同；
• 软链接的文件类型是“l”，可以用rm删除。

融会贯通后你会发现：

1. 删除符号连接tmpsoft,对tmp,tmphard无影响；
2. 删除硬连接tmphard，对tmp,tmpsoft也无影响；
3. 删除原文件tmp，对硬连接tmphard没有影响，导致符号连接tmpsoft失效；
4. 同时删除原文件tmp,硬连接tmphard，整个文件会真正的被删除。
5. 我们再向这个软链接写点东西,则可以看到，刚才删除的tmp文件竟然又出现了！这就说明，当我们写入访问软链接时，系统自动将其路径替换为其所代表的绝对路径，并直接访问那个路径了。

#删除tmp
➜  ~ rm tmp
➜  ~ ls -ilrth tmp*
38351334 -rw-r--r--  1 hanzhu  staff     0B Oct  9 20:41 tmphard
38364003 lrwxr-xr-x  1 hanzhu  staff     3B Oct  9 21:58 tmpsoft -> tmp

#对硬链接无影响（本来就是空文档）
➜  ~ cat tmphard

#软链接失效
➜  ~ cat tmpsoft
cat: tmpsoft: No such file or directory

#我们再向这个软链接写点东西
➜  ~ echo >> tmpsoft
➜  ~ ls -ilrth tmp*
38351334 -rw-r--r--  1 hanzhu  staff     0B Oct  9 20:41 tmphard
38364003 lrwxr-xr-x  1 hanzhu  staff     3B Oct  9 21:58 tmpsoft -> tmp
38377261 -rw-r--r--  1 hanzhu  staff     1B Oct  9 23:07 tmp

硬链接和软链接的区别

原理上，硬链接和源文件的inode节点号相同，两者互为硬链接。软连接和源文件的inode节点号不同，进而指向的block也不同，软连接block中存放了源文件的路径名。

实际上，硬链接和源文件是同一份文件，而软连接是独立的文件，类似于快捷方式，存储着源文件的位置信息便于指向。

使用限制上，不能对目录创建硬链接，不能对不同文件系统创建硬链接，不能对不存在的文件创建硬链接；可以对目录创建软连接，可以跨文件系统创建软连接，可以对不存在的文件创建软连接。

References:
Linux硬链接和软连接的区别与总结
关于硬链接和软连接（符号链接）的区别
5分钟让你明白“软链接”和“硬链接”的区别

关于进程与线程，请移步进程与线程。
本文并非原创，而是拼接整理各作者博文，主要还是为了梳理学习，在此一并致谢并将references贴在文末。

正文

linux下的进程通信手段基本上是从Unix平台上的进程通信手段继承而来的。而对Unix发展做出重大贡献的两大主力AT&T的贝尔实验室及BSD（加州大学伯克利分校的伯克利软件发布中心）在进程间通信方面的侧重点有所不同。
前者对Unix早期的进程间通信手段进行了系统的改进和扩充，形成了“system V IPC”，通信进程局限在单个计算机内；
后者则跳过了该限制，形成了基于套接口（socket）的进程间通信机制。
Linux则把两者继承了下来

• 早期UNIX进程间通信
• 基于System V进程间通信
• 基于Socket进程间通信
• POSIX进程间通信。

UNIX进程间通信方式包括：管道、FIFO、信号。
System V进程间通信方式包括：System V消息队列、System V信号灯、System V共享内存
POSIX进程间通信包括：posix消息队列、posix信号灯、posix共享内存。

由于Unix版本的多样性，电子电气工程协会（IEEE）开发了一个独立的Unix标准，这个新的ANSI Unix标准被称为计算机环境的可移植性操作系统界面（PSOIX）。现有大部分Unix和流行版本都是遵循POSIX标准的，而Linux从一开始就遵循POSIX标准；
BSD并不是没有涉足单机内的进程间通信（socket本身就可以用于单机内的进程间通信）。事实上，很多Unix版本的单机IPC留有BSD的痕迹，如4.4BSD支持的匿名内存映射、4.3+BSD对可靠信号语义的实现等等。

1. Pipe管道

• 管道是半双工的通信，数据只能单向流动，需要双方通信时，需要建立起两个管道；
• 只能在具有亲缘关系的进程间使用，进程的亲缘关系通常是指父子进程关系。
• 单独构成一种独立的文件系统：管道对于管道两端的进程而言，就是一个文件，但它不是普通的文件，它不属于某种文件系统，而是自立门户，单独构成一种文件系统，并且只存在与内存中。
• 数据的读出和写入：一个进程向管道中写的内容被管道另一端的进程读出。写入的内容每次都添加在管道缓冲区的末尾，并且每次都是从缓冲区的头部读出数据。
  

管道的实质：
管道的实质是一个内核缓冲区，进程以先进先出的方式从缓冲区存取数据，管道一端的进程顺序的将数据写入缓冲区，另一端的进程则顺序的读出数据。
该缓冲区可以看作是一个循环队列，读和写的位置都是自动增长的，不能随意改变，一个数据只能被读一次，读出来以后在缓冲区就不复存在了。
当缓冲区读空或者写满时，有一定的规则控制相应的读进程或者写进程进入等待队列，当空的缓冲区有新数据写入或者满的缓冲区有数据读出来时，就唤醒等待队列中的进程继续读写。

管道的局限：
管道的主要局限性正体现在它的特点上：

• 只支持单向数据流；
• 只能用于具有亲缘关系的进程之间；
• 没有名字；
• 管道的缓冲区是有限的（管道制存在于内存中，在管道创建时，为缓冲区分配一个页面大小）；
• 管道所传送的是无格式字节流，这就要求管道的读出方和写入方必须事先约定好数据的格式，比如多少字节算作一个消息（或命令、或记录）等等；
  流管道s_pipe: 去除了第一种限制,可以双向传输.
  管道可用于具有亲缘关系进程间的通信，命名管道:name_pipe克服了管道没有名字的限制，因此，除具有管道所具有的功能外，它还允许无亲缘关系进程间的通信；

2. FIFO匿名管道

匿名管道，由于没有名字，只能用于亲缘关系的进程间通信。为了克服这个缺点，提出了有名管道(FIFO)。在磁盘上有对应的索引节点，但没有数据块——换言之，只是拥有一个名字和相应的访问权限，通过mknode()系统调用或者mkfifo()函数来建立的。一旦建立，任何进程都可以通过文件名将其打开和进行读写，而不局限于父子进程，当然前提是进程对FIFO有适当的访问权。当不再被进程使用时，FIFO在内存中释放，但磁盘节点仍然存在。

有名管道不同于匿名管道之处在于它提供了一个路径名与之关联，以有名管道的文件形式存在于文件系统中，这样，即使与有名管道的创建进程不存在亲缘关系的进程，只要可以访问该路径，就能够彼此通过有名管道相互通信，因此，通过有名管道不相关的进程也能交换数据。值得注意的是，有名管道严格遵循先进先出(first in first out),对匿名管道及有名管道的读总是从开始处返回数据，对它们的写则把数据添加到末尾。它们不支持诸如lseek()等文件定位操作。有名管道的名字存在于文件系统中，内容存放在内存中。

匿名管道和有名管道总结：
（1）管道是特殊类型的文件，在满足先入先出的原则条件下可以进行读写，但不能进行定位读写。
（2）匿名管道是单向的，只能在有亲缘关系的进程间通信；有名管道以磁盘文件的方式存在，可以实现本机任意两个进程通信。
（3）无名管道阻塞问题：无名管道无需显示打开，创建时直接返回文件描述符，在读写时需要确定对方的存在，否则将退出。如果当前进程向无名管道的一端写数据，必须确定另一端有某一进程。如果写入无名管道的数据超过其最大值，写操作将阻塞，如果管道中没有数据，读操作将阻塞，如果管道发现另一端断开，将自动退出。
（4）有名管道阻塞问题：有名管道在打开时需要确实对方的存在，否则将阻塞。即以读方式打开某管道，在此之前必须一个进程以写方式打开管道，否则阻塞。此外，可以以读写（O_RDWR）模式打开有名管道，即当前进程读，当前进程写，不会阻塞。

延伸阅读：该博客有匿名管道和有名管道的C语言实践

3. 信号量( semaphore )

信号量是一个计数器，可以用来控制多个进程对共享资源的访问。信号量用于实现进程间的互斥与同步，而不是用于存储进程间通信数据。它常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
信号量基于操作系统的 PV 操作，程序对信号量的操作都是原子操作。
信号是比较复杂的通信方式，用于通知接受进程有某种事件发生，除了用于进程间通信外，进程还可以发送信号给进程本身；linux除了支持Unix早期信号语义函数sigal外，还支持语义符合Posix.1标准的信号函数sigaction（实际上，该函数是基于BSD的，BSD为了实现可靠信号机制，又能够统一对外接口，用sigaction函数重新实现了signal函数）；

信号量的本质是一种数据操作锁，它本身不具有数据交换的功能，而是通过控制其他的通信资源（文件，外部设备）来实现进程间通信，它本身只是一种外部资源的标识。信号量在此过程中负责数据操作的互斥、同步等功能。
当请求一个使用信号量来表示的资源时，进程需要先读取信号量的值来判断资源是否可用。大于0，资源可以请求，等于0，无资源可用，进程会进入睡眠状态直至资源可用。
当进程不再使用一个信号量控制的共享资源时，信号量的值+1，对信号量的值进行的增减操作均为原子操作，这是由于信号量主要的作用是维护资源的互斥或多进程的同步访问。而在信号量的创建及初始化上，不能保证操作均为原子性。

信号量是一个计数器，用于多进程对共享数据的访问，信号量的意图在于进程间同步。
为了获得共享资源，进程需要执行下列操作：
（1）创建一个信号量：这要求调用者指定初始值，对于二值信号量来说，它通常是1，也可是0。
（2）等待一个信号量：该操作会测试这个信号量的值，如果小于0，就阻塞。也称为P操作。
（3）挂出一个信号量：该操作将信号量的值加1，也称为V操作。
为了正确地实现信号量，信号量值的测试及减1操作应当是原子操作。为此，信号量通常是在内核中实现的。Linux环境中，有三种类型：Posix（可移植性操作系统接口）有名信号量（使用Posix IPC名字标识）、Posix基于内存的信号量（存放在共享内存区中）、System V信号量（在内核中维护）。这三种信号量都可用于进程间或线程间的同步。

信号量与普通整型变量的区别：
（1）信号量是非负整型变量，除了初始化之外，它只能通过两个标准原子操作：wait(semap) , signal(semap) ; 来进行访问；
（2）操作也被称为PV原语（P来源于荷兰语proberen"测试"，V来源于荷兰语verhogen"增加"，P表示通过的意思，V表示释放的意思），而普通整型变量则可以在任何语句块中被访问；

信号量与互斥量之间的区别：
（1）互斥量用于线程的互斥，信号量用于线程的同步。这是互斥量和信号量的根本区别，也就是互斥和同步之间的区别。
互斥：是指某一资源同时只允许一个访问者对其进行访问，具有唯一性和排它性。但互斥无法限制访问者对资源的访问顺序，即访问是无序的。
同步：是指在互斥的基础上（大多数情况），通过其它机制实现访问者对资源的有序访问。
在大多数情况下，同步已经实现了互斥，特别是所有写入资源的情况必定是互斥的。少数情况是指可以允许多个访问者同时访问资源
（2）互斥量值只能为0/1，信号量值可以为非负整数。
也就是说，一个互斥量只能用于一个资源的互斥访问，它不能实现多个资源的多线程互斥问题。信号量可以实现多个同类资源的多线程互斥和同步。当信号量为单值信号量是，也可以完成一个资源的互斥访问。
（3）互斥量的加锁和解锁必须由同一线程分别对应使用，信号量可以由一个线程释放，另一个线程得到。

4. 消息队列( message queue )

消息队列是由消息的链表，存放在内核中并由消息队列标识符标识。消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。

消息队列是消息的链接表，包括Posix消息队列system V消息队列。
消息队列与管道通信相比，其优势是对每个消息指定特定的消息类型，接收的时候不需要按照队列次序，而是可以根据自定义条件接收特定类型的消息。
可以把消息看做一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息，对消息队列有读权限的进程可以从消息队列中读取消息。

• 消息队列是存放在内核中的消息链表，每个消息队列由消息队列标识符表示。
• 与管道（无名管道：只存在于内存中的文件；命名管道：存在于实际的磁盘介质或者文件系统）不同的是消息队列存放在内核中，只有在内核重启(即，操作系统重启)或者显示地删除一个消息队列时，该消息队列才会被真正的删除。
• 另外与管道不同的是，消息队列在某个进程往一个队列写入消息之前，并不需要另外某个进程在该队列上等待消息的到达。

消息队列特点总结：
（1）消息队列是消息的链表,具有特定的格式,存放在内存中并由消息队列标识符标识.
（2）消息队列允许一个或多个进程向它写入与读取消息.
（3）管道和消息队列的通信数据都是先进先出的原则。
（4）消息队列可以实现消息的随机查询,消息不一定要以先进先出的次序读取,也可以按消息的类型读取.比FIFO更有优势。
（5）消息队列克服了信号承载信息量少，管道只能承载无格式字 节流以及缓冲区大小受限等缺。
（6）目前主要有两种类型的消息队列：POSIX消息队列以及System V消息队列，系统V消息队列目前被大量使用。系统V消息队列是随内核持续的，只有在内核重启或者人工删除时，该消息队列才会被删除。

延伸阅读：消息队列C语言的实践

5. 信号 ( singal )

信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生。主要作为进程间以及同一进程不同线程之间的同步手段。

• 信号是Linux系统中用于进程间互相通信或者操作的一种机制，信号可以在任何时候发给某一进程，而无需知道该进程的状态。
• 如果该进程当前并未处于执行状态，则该信号就有内核保存起来，直到该进程恢复执行并传递给它为止。
• 如果一个信号被进程设置为阻塞，则该信号的传递被延迟，直到其阻塞被取消时才被传递给进程。

Linux系统中常用信号：
（1）SIGHUP：用户从终端注销，所有已启动进程都将收到该进程。系统缺省状态下对该信号的处理是终止进程。
（2）SIGINT：程序终止信号。程序运行过程中，按Ctrl+C键将产生该信号。
（3）SIGQUIT：程序退出信号。程序运行过程中，按Ctrl+\键将产生该信号。
（4）SIGBUS和SIGSEGV：进程访问非法地址。
（5）SIGFPE：运算中出现致命错误，如除零操作、数据溢出等。
（6）SIGKILL：用户终止进程执行信号。shell下执行kill -9发送该信号。
（7）SIGTERM：结束进程信号。shell下执行kill 进程pid发送该信号。
（8）SIGALRM：定时器信号。
（9）SIGCLD：子进程退出信号。如果其父进程没有忽略该信号也没有处理该信号，则子进程退出后将形成僵尸进程。

信号来源
信号是软件层次上对中断机制的一种模拟，是一种异步通信方式，信号可以在用户空间进程和内核之间直接交互，内核可以利用信号来通知用户空间的进程发生了哪些系统事件，信号事件主要有两个来源：

• 硬件来源：用户按键输入Ctrl+C退出、硬件异常如无效的存储访问等。
• 软件终止：终止进程信号、其他进程调用kill函数、软件异常产生信号。

一旦有信号产生，用户进程对信号产生的相应有三种方式：
1）执行默认操作，linux对每种信号都规定了默认操作。
2）捕捉信号，定义信号处理函数，当信号发生时，执行相应的处理函数。
3）忽略信号，当不希望接收到的信号对进程的执行产生影响，而让进程继续执行时，可以忽略该信号，即不对信号进程作任何处理。
有两个信号是应用进程无法捕捉和忽略的，即SIGKILL和SEGSTOP，这是为了使系统管理员能在任何时候中断或结束某一特定的进程。

信号生命周期和处理流程
（1）信号被某个进程产生，并设置此信号传递的对象（一般为对应进程的pid），然后传递给操作系统；
（2）操作系统根据接收进程的设置（是否阻塞）而选择性的发送给接收者，如果接收者阻塞该信号（且该信号是可以阻塞的），操作系统将暂时保留该信号，而不传递，直到该进程解除了对此信号的阻塞（如果对应进程已经退出，则丢弃此信号），如果对应进程没有阻塞，操作系统将传递此信号。
（3）目的进程接收到此信号后，将根据当前进程对此信号设置的预处理方式，暂时终止当前代码的执行，保护上下文（主要包括临时寄存器数据，当前程序位置以及当前CPU的状态）、转而执行中断服务程序，执行完成后在回复到中断的位置。当然，对于抢占式内核，在中断返回时还将引发新的调度。

6. 共享内存( shared memory )

共享内存就是映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问。共享内存是最快的 IPC 方式，它是针对其他进程间通信方式运行效率低而专门设计的。它往往与其他通信机制，如信号量，配合使用，来实现进程间的同步和通信。

• 使得多个进程可以访问同一块内存空间，是最快的可用IPC形式。是针对其他通信机制运行效率较低而设计的。
• 为了在多个进程间交换信息，内核专门留出了一块内存区，可以由需要访问的进程将其映射到自己的私有地址空间。进程就可以直接读写这一块内存而不需要进行数据的拷贝，从而大大提高效率。
• 由于多个进程共享一段内存，因此需要依靠某种同步机制（如信号量）来达到进程间的同步及互斥。
  
  共享内存的优缺点：
  1、优点：我们可以看到使用共享内存进行进程间的通信真的是非常方便，而且函数的接口也简单，数据的共享还使进程间的数据不用传送，而是直接访问内存，也加快了程序的效率。同时，它也不像匿名管道那样要求通信的进程有一定的父子关系。
  2、缺点：共享内存没有提供同步的机制，这使得我们在使用共享内存进行进程间通信时，往往要借助其他的手段来进行进程间的同步工作。

采用共享内存进行通信的一个主要好处是效率高，因为进程可以直接读写内存，而不需要任何数据的拷贝，对于像管道和消息队里等通信方式，则需要在内核和用户空间进行四次的数据拷贝，而共享内存则只拷贝两次：一次从输入文件到共享内存区，另一次从共享内存到输出文件。
一般而言，进程之间在共享内存时，并不总是读写少量数据后就解除映射，有新的通信时在重新建立共享内存区域；而是保持共享区域，直到通信完毕为止，这样，数据内容一直保存在共享内存中，并没有写回文件。共享内存中的内容往往是在解除映射时才写回文件，因此，采用共享内存的通信方式效率非常高。

共享内存有两种实现方式：1、内存映射 2、共享内存机制
1、内存映射
内存映射 memory map机制使进程之间通过映射同一个普通文件实现共享内存，通过mmap()系统调用实现。普通文件被映射到进程地址空间后，进程可以像访问普通内存一样对文件进行访问，不必再调用read/write等文件操作函数。
2、UNIX System V共享内存机制
IPC的共享内存指的是把所有的共享数据放在共享内存区域（IPC shared memory region），任何想要访问该数据的进程都必须在本进程的地址空间新增一块内存区域，用来映射存放共享数据的物理内存页面。
和前面的mmap系统调用通过映射一个普通文件实现共享内存不同，UNIX system V共享内存是通过映射特殊文件系统shm中的文件实现进程间的共享内存通信。

延伸阅读：Linux支持的主要三种共享内存方式：mmap()系统调用、Posix共享内存，以及System V共享内存实践

7. 套接字( socket )

套接字也是一种进程间通信机制，与其他通信机制不同的是，它可用于不同机器间的进程通信
更为一般的进程间通信机制，可用于不同机器之间的进程间通信。起初是由Unix系统的BSD分支开发出来的，但现在一般可以移植到其它类Unix系统上：Linux和System V的变种都支持套接字。

套接字是一种通信机制，凭借这种机制，客户/服务器（即要进行通信的进程）系统的开发工作既可以在本地单机上进行，也可以跨网络进行。也就是说它可以让不在同一台计算机但通过网络连接计算机上的进程进行通信。

套接字是支持TCP/IP的网络通信的基本操作单元，可以看做是不同主机之间的进程进行双向通信的端点，简单的说就是通信的两方的一种约定，用套接字中的相关函数来完成通信过程。

套接字特性
套接字的特性由3个属性确定，它们分别是：域、端口号、协议类型。
（1）套接字的域
它指定套接字通信中使用的网络介质，最常见的套接字域有两种：
一是AF_INET，它指的是Internet网络。当客户使用套接字进行跨网络的连接时，它就需要用到服务器计算机的IP地址和端口来指定一台联网机器上的某个特定服务，所以在使用socket作为通信的终点，服务器应用程序必须在开始通信之前绑定一个端口，服务器在指定的端口等待客户的连接。
另一个域AF_UNIX，表示UNIX文件系统，它就是文件输入/输出，而它的地址就是文件名。
（2）套接字的端口号
每一个基于TCP/IP网络通讯的程序(进程)都被赋予了唯一的端口和端口号，端口是一个信息缓冲区，用于保留Socket中的输入/输出信息，端口号是一个16位无符号整数，范围是0-65535，以区别主机上的每一个程序（端口号就像房屋中的房间号），低于256的端口号保留给标准应用程序，比如pop3的端口号就是110，每一个套接字都组合进了IP地址、端口，这样形成的整体就可以区别每一个套接字。
（3）套接字协议类型
因特网提供三种通信机制，
一是流套接字，流套接字在域中通过TCP/IP连接实现，同时也是AF_UNIX中常用的套接字类型。流套接字提供的是一个有序、可靠、双向字节流的连接，因此发送的数据可以确保不会丢失、重复或乱序到达，而且它还有一定的出错后重新发送的机制。
二个是数据报套接字，它不需要建立连接和维持一个连接，它们在域中通常是通过UDP/IP协议实现的。它对可以发送的数据的长度有限制，数据报作为一个单独的网络消息被传输,它可能会丢失、复制或错乱到达，UDP不是一个可靠的协议，但是它的速度比较高，因为它并一需要总是要建立和维持一个连接。
三是原始套接字，原始套接字允许对较低层次的协议直接访问，比如IP、 ICMP协议，它常用于检验新的协议实现，或者访问现有服务中配置的新设备，因为RAW SOCKET可以自如地控制Windows下的多种协议，能够对网络底层的传输机制进行控制，所以可以应用原始套接字来操纵网络层和传输层应用。比如，我们可以通过RAW SOCKET来接收发向本机的ICMP、IGMP协议包，或者接收TCP/IP栈不能够处理的IP包，也可以用来发送一些自定包头或自定协议的IP包。网络监听技术很大程度上依赖于SOCKET_RAW。

原始套接字与标准套接字的区别在于：
原始套接字可以读写内核没有处理的IP数据包，而流套接字只能读取TCP协议的数据，数据报套接字只能读取UDP协议的数据。因此，如果要访问其他协议发送数据必须使用原始套接字。

套接字通信的建立

服务器端
（1）首先服务器应用程序用系统调用socket来创建一个套接字，它是系统分配给该服务器进程的类似文件描述符的资源，它不能与其他的进程共享。
（2）然后，服务器进程会给套接字起个名字，我们使用系统调用bind来给套接字命名。然后服务器进程就开始等待客户连接到这个套接字。
（3）接下来，系统调用listen来创建一个队列并将其用于存放来自客户的进入连接。
（4）最后，服务器通过系统调用accept来接受客户的连接。它会创建一个与原有的命名套接不同的新套接字，这个套接字只用于与这个特定客户端进行通信，而命名套接字（即原先的套接字）则被保留下来继续处理来自其他客户的连接（建立客户端和服务端的用于通信的流，进行通信）。
客户端
（1）客户应用程序首先调用socket来创建一个未命名的套接字，然后将服务器的命名套接字作为一个地址来调用connect与服务器建立连接。
（2）一旦连接建立，我们就可以像使用底层的文件描述符那样用套接字来实现双向数据的通信（通过流进行数据传输）。

8. Unix域套接字（Unix domain socket)

用于在同一台机器上运行的进程之间的通信。虽然因特网域套接字可用于同一目的，但UNIX域套接字的效率更高。UNIX域套接字仅仅复制数据；它们并不执行协议处理，不需要添加或删除网络报头，无需计算检验和，不要产生顺序号，无需发送确认报文。

Refs:
进程间通信IPC (InterProcess Communication)
Linux进程间通信的几种方式总结--linux内核剖析（七）
进程间通信--管道
进程间通信的方式——信号、管道、消息队列、共享内存
Linux进程间通信——使用共享内存
进程间通信---共享内存
Linux进程间通信(四) - 共享内存
信号量与互斥锁
信号量
看图理解进程间通信IPC
进程和线程的概念、区别及进程线程间通信

进程间通信还请移步：进程间通信 Inter-Process Communication

进程：运行时程序的封装，是系统进行资源调度和分配的的基本单位，实现了操作系统的并发；每个进程都有自己独立的一块内存空间，一个进程可以有多个线程。

线程：进程中的子任务（控制单元），是CPU调度和分派的基本单位，用于保证程序的实时性，实现进程内部的并发；线程是操作系统可识别的最小执行和调度单位。 每个线程都独自占用一个虚拟处理器：独自的寄存器组，指令计数器和处理器状态。每个线程完成不同的任务，但是共享同一地址空间（也就是同样的动态内存，映射文件，目标代码等等），打开的文件队列和其他内核资源。

进程与线程的区别总结
线程具有许多传统进程所具有的特征，故又称为轻型进程(Light—Weight Process)或进程元；而把传统的进程称为重型进程(Heavy—Weight Process)，它相当于只有一个线程的任务。在引入了线程的操作系统中，通常一个进程都有若干个线程，至少包含一个线程。

• 根本区别：进程是操作系统资源分配的基本单位，而线程是处理器任务调度和执行的基本单位
• 资源开销：每个进程都有独立的代码和数据空间（程序上下文），程序之间的切换会有较大的开销；线程可以看做轻量级的进程，同一类线程共享代码和数据空间，每个线程都有自己独立的运行栈和程序计数器（PC），线程之间切换的开销小。
• 包含关系：如果一个进程内有多个线程，则执行过程不是一条线的，而是多条线（线程）共同完成的；线程是进程的一部分，所以线程也被称为轻权进程或者轻量级进程。
• 内存分配：同一进程的线程共享本进程的地址空间和资源，而进程之间的地址空间和资源是相互独立的
• 影响关系：一个进程崩溃后，在保护模式下不会对其他进程产生影响，但是一个线程崩溃整个进程都死掉。所以多进程要比多线程健壮。
• 通信：由于同一进程中的多个线程具有相同的地址空间，致使它们之间的同步和通信的实现，也变得比较容易。进程间通信IPC，线程间可以直接读写进程数据段（如全局变量）来进行通信——需要进程同步和互斥手段的辅助，以保证数据的一致性。 在有的系统中，线程的切换、同步和通信都无须操作系统内核的干预
• 进程编程调试简单可靠性高，但是创建销毁开销大；线程正相反，开销小，切换速度快，但是编程调试相对复杂
• 执行过程：每个独立的进程有程序运行的入口、顺序执行序列和程序出口。但是线程不能独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制，两者均可并发执行
• 进程适应于多核、多机分布；线程适用于多核

References:
https://blog.csdn.net/ThinkWon/article/details/102021274
https://www.liaoxuefeng.com/wiki/1016959663602400/1017631469467456
https://wizardforcel.gitbooks.io/wangdaokaoyan-os/content/7.html

JAVA:
廖雪峰什么是泛型
泛型就这么简单
深入理解 Java 泛型

Python:
关于python支持泛型的讨论
白学这么多年 Python ？连泛型函数都不会写？

本文非原创，是下列一系列文章的集合，帮助理解。

Answer 1

https://www.zhihu.com/question/19918532/answer/21647195

类型系统的一些概念，众说纷纭，使用上也比较乱。有些东西，甚至不好严格定义。以下算学术界的一种相对“严格”的说法。

1. 先定义一些基础概念

Program Errors

• trapped errors。导致程序终止执行，如除0，Java中数组越界访问
• untrapped errors。 出错后继续执行，但可能出现任意行为。如C里的缓冲区溢出、Jump到错误地址

Forbidden Behaviours
语言设计时，可以定义一组forbidden behaviors. 它必须包括所有untrapped errors, 但可能包含trapped errors.

Well behaved、ill behaved

• well behaved: 如果程序执行不可能出现forbidden behaviors, 则为well behaved。
• ill behaved: 否则为ill behaved...

2. 有了上面的概念，再讨论强、弱类型，静态、动态类型

强、弱类型

• 强类型strongly typed: 如果一种语言的所有程序都是well behaved——即不可能出现forbidden behaviors，则该语言为strongly typed。
• 弱类型weakly typed: 否则为weakly typed。比如C语言的缓冲区溢出，属于trapped errors，即属于forbidden behaviors..故C是弱类型

前面的人也说了，弱类型语言，类型检查更不严格，如偏向于容忍隐式类型转换。譬如说C语言的int可以变成double。 这样的结果是：容易产生forbidden behaviours，所以是弱类型的

动态、静态类型

• 静态类型 statically: 如果在编译时拒绝ill behaved程序，则是statically typed;
• 动态类型dynamiclly: 如果在运行时拒绝ill behaviors, 则是dynamiclly typed。

3. 误区

大家觉得C语言要写int a, int b之类的，Python不用写(可以直接写a, b)，所以C是静态，Python是动态。这么理解是不够准确的。譬如Ocaml是静态类型的，但是也可以不用明确地写出来。。Ocaml是静态隐式类型

静态类型可以分为两种：

• 如果类型是语言语法的一部分，在是explicitly typed显式类型；
• 如果类型通过编译时推导，是implicity typed隐式类型, 比如ML和Haskell

4.下面是些例子

无类型： 汇编
弱类型、静态类型 ： C/C++
弱类型、动态类型检查： Perl/PHP
强类型、静态类型检查 ：Java/C#
强类型、动态类型检查 ：Python, Scheme
静态显式类型 ：Java/C
静态隐式类型 ：Ocaml, Haskell

===============

Answer 2

https://www.zhihu.com/question/19918532/answer/47112288

前面 @姚培森 给的定义比较详细，但我觉得并不易于理解，而且我看到评论里已经有人产生了一些误解。我的理解是，这些概念本身就只是一种通俗的说法，并没有严格的定义，只能勉强用一些术语来厘清边界。下面是《Programming Language：Application and Interpretation》里给的一种解释，我觉得更易于理解：

从图上看，静态类型、动态类型大家应该明白其实是指的Type Check发生的时机。而强类型、弱类型到底是什么意思呢？其实这些词语本身概念就是模糊不清的，反正我是能避免使用就尽量避免使用。So what is “strong typing”?

This appears to be a meaningless phrase, and people often use it in a non-sensical fashion. To some it seems to mean “The language has a type checker”. To others it means “The language is sound” (that is, the type checker and run-time system are related). To most, it seems to justmean, “A language like Pascal, C or Java, related in a way I can’t quite make precise”. If someone uses thisphrase, be sure to ask them to define it for you. (For amusement, watch them squirm.)

@刘典 在 @姚培森 的回答下面提了一个疑问，我理了一下这个逻辑：

• 按照定义，如果在编译时拒绝ill behaved程序，则是statically typed。
• 按照定义，如果一种语言的所有程序都是well behaved，则该语言为strongly typed。
• 那么，所有statically typed语言都是well behaved，即strongly typed。

这逻辑错在哪里呢？问题在于：在编译时拒绝（部分）ill behaved是编译器的行为，并不是概念上的定义。事实上，问题正出在 「Statically Typed」这个词身上！

可以这么说，并不存在 Statically Typed，只有 Statically Checked。
http://lucacardelli.name/papers/typesystems.pdf

In general, we avoid the words type and typing when referring to run time concepts; for example we replace dynamic typing with dynamic checking and avoid common but ambiguous terms such as strong typing.

因为它不是语言固有属性，而是编译器的行为，搞清这点就不会产生误解了。可能有人会问，既然Statically Typed 不是语言固有属性，那C\C++、Java的类型声明又怎么解释呢？前面说了，那叫「Explicitly Typed」，类型是语言语法的一部分，但到底是静态检查还是运行期检查，或者是根本不检查，那就是编译器解释器的行为了。比如PHP有Type Hint，看上去就像 Explicitly Typed，但它是运行到那行代码才检查，仍然不是Statically Checked。好了，现在静态类型动态类型算是搞清楚了吧。

那 Type Safety 呢？

Type safety is the property that no primitive operation ever applies to values of the wrong type. By primitive operation we mean not only addition and so forth, but also procedure application. A safe language honors the abstraction boundaries it erects.

这也算是通俗的解释了，符合大众印象，大家所理解的强类型、类型安全等，通常都是指运算符和函数调用，比如将原本作用于Int的“*”去用到字符串上是不合法的，程序不会继续往下执行。

为什么C/C++ 是Type unsafe呢？注意，type是和value绑定到一起的，所以：

int a = 4;
char* s = (char*)a; //假设类型转换OK通过编译
void f(char* s);
f(s); // unsafe

C/C++ 本不具备一个 Sound Type System，即它的类型系统本身就并不能保证安全。

为什么大家认为Python是强类型呢？也就是说他们倾向于认为Python是类型安全的？CPython解释器就是Python语言事实上的标准，所以我们就直接看Python解释器的行为了，它会在运行期检测类型错误，程序会中断执行：

class A:
  def halo(self):
    print "A"

class B: 
  pass

A.halo(B()) # 抛出 TypeError,如果B继承自A则不会报错

当然，ctypes这种东西我们就不考虑了。相比之下，JavaScript就很明显谈不上类型安全，但这也取决于你的定义，如果你将类型安全的定义放宽，也可以认为 JavaScript 类型安全，比如调用不存在的方法 JS 也会中断执行。

断言type assertion提供了access to an interface value's underlying concrete value.

直接断言

t := i.(T)

This statement asserts that the interface value i holds the concrete type T and assigns the underlying T value to the variable t.

If i does not hold a T, the statement will trigger a panic.直接断言会导致panic。

测试断言

To test whether an interface value holds a specific type, a type assertion can return two values: the underlying value and a boolean value that reports whether the assertion succeeded.

t, ok := i.(T)

If i holds a T, then t will be the underlying value and ok will be true.

If not, ok will be false and t will be the zero value of type T, and no panic occurs.

Note the similarity between this syntax and that of reading from a map.

示例：

package main

import "fmt"

func main() {
	var i interface{} = "hello"

	s := i.(string)
	fmt.Println(s)

	s, ok := i.(string)
	fmt.Println(s, ok)

	f, ok := i.(float64)
	fmt.Println(f, ok)

	f = i.(float64) // panic
	fmt.Println(f)
}

输出

hello
hello true
0 false
panic: interface conversion: interface {} is string, not float64

goroutine 1 [running]:
main.main()
	/tmp/sandbox227310573/prog.go:17 +0x1fe

配合Switch

另外也可以配合switch语句进行判断：

package main

import "fmt"

func findType(i interface{}) {
    switch x := i.(type) {
    case int:
        fmt.Println(x, "is int")
    case string:
        fmt.Println(x, "is string")
    case nil:
        fmt.Println(x, "is nil")
    default:
        fmt.Println(x, "not type matched")
    }
}

func main() {
    findType(10)      // int
    findType("hello") // string

    var k interface{} // nil
    findType(k)

    findType(10.23) //float64
}

运行结果：

10 is int
hello is string
<nil> is nil
10.23 not type matched

References:
https://studygolang.com/articles/3314

Threading vs Multiprocessing

Threading:

• A new thread is spawned within the existing process
• Starting a thread is faster than starting a process
• Memory is shared between all threads
• Mutexes often necessary to control access to shared data
• One GIL (Global Interpreter Lock) for all threads

Multiprocessing:

• A new process is started independent from the first process
• Starting a process is slower than starting a thread
• Memory is not shared between processes
• Mutexes not necessary (unless threading in the new process)
• One GIL (Global Interpreter Lock) for each process

跑Threading时，只有一个CPU占满，因为GIL锁住了；Multiprocessing时，所有core都占满了。虽然Threading不可以in parallel, 它可以concurrently,通过切片来回跳。

Threading适合I/O bound的task，因为需要等待磁盘或者网络响应。如果是CPU bound的任务，则便宜不大。

传统做法示例代码：

import threading
import time

start = time.perf_counter()

def do_something(seconds):
    print(f'Sleeping {seconds} second...')
    time.sleep(seconds)
    print('Done Sleeping...')

threads = []
    
for _ in range(10):
    #先设置，还没跑
    t = threading.Thread(target=do_something, args=[1.5])
    #开始跑
    t.start()
    #不能在loop内join是因为它会join on the thread before looping through and creating and starting the next thread，本质上与synchronously跑无异
    #所以需要办法先start threads in one loop，然后再次loop through the threads again and then run the join method on them
    #做法是append去一个list
    threads.append(t)

for thread in threads:
    thread.join()

    
finish = time.perf_counter()

print (f'Finished in {round(finish-start,2)} second(s)')

Python3.2之后有了thread pool executor, 更方便高效也可以更方便切换去multiple processes，如果有需求的话:

import concurrent.futures
import time

start = time.perf_counter()

def do_something(seconds):
    print(f'Sleeping {seconds} second...')
    time.sleep(seconds)
    return f'Done Sleeping...{seconds}'

with concurrent.futures.ThreadPoolExecutor() as executor:
    #submit方法schedules a function to be executed and returns a future object.
    #future object encapsulates executation of our function, 还允许你在scheduled后查看它, run, done,或者result  
    
    secs = [5,4,3,2,1]
    #此处用到List comprehension
    results = [executor.submit(do_something, sec) for sec in secs]
    
    for f in concurrent.futures.as_completed(results):
        print(f.result())
    
#     f1 = executor.submit(do_something, 1)
#     f2 = executor.submit(do_something, 1)
#     print(f1.result())
#     print(f2.result())
    
    
finish = time.perf_counter()

print (f'Finished in {round(finish-start,2)} second(s)')

（还可以加上multiprocessing的例子，索性讲讲透）

Reference:
https://www.youtube.com/watch?v=ecKWiaHCEKs
https://www.youtube.com/watch?v=IEEhzQoKtQU&t=19s
https://www.liaoxuefeng.com/wiki/1016959663602400/1017628290184064
https://www.liaoxuefeng.com/wiki/1016959663602400/1017629247922688
https://timber.io/blog/multiprocessing-vs-multithreading-in-python-what-you-need-to-know/