举例理解什么是进程，线程

Junwind 的个人博客 / 765 / 6 / 创建于 2年前 / 更新于 2年前

如果理解的不好，欢迎评论指出错误

cpu的单核一次可运行一个进程，多个进程切换运行，多核则可同时运行多个进程
cpu的核就像一个工厂，进程就像工厂中的车间（提供工人的工作条件，环境+库+依赖，即运行时的环境），线程就像车间中的工人，负责工作具体的任务；
即线程是具体做事的基本单位，进程是能调用各种资源的基本单位；

或者再举个例子说明进程和线程：
    进程就像技术部负责人，他平时只负责管理下面的技术员，分配任务，管理进度，提供额外技术支持； 技术员是干活的人，但是负责人也是可以干活的，即进程也是可以做干活的人；

比如一个单进程，就像一个单人独立工作室，他什么都得干；和其它的单人独立工作室是没有关系的，不能做资源共享；（可以依托中间人资源转交，如redis可以使多个进程资源共享）

单进程多线程，就像一个独立团队，带头人就是这个主进程，其他工作人员就是多个的线程，这个团队里面，每个人都可以共享团队的资源（即单进程里面的多线程是可以共享内存数据的）


进程，线程？
    单线程和多线程并没有高低，各有优劣，适应的场景不同，或者说实现的机制不同

    单进程：
        比如我们有一个餐厅（进程），准备好了吃饭，做饭等的环境（运行时环境）；这个餐厅中的资源，该餐厅中的每个服务员（线程）都是可以共享的（内存数据可共享）

    多进程：
        我们有多个连锁的餐厅；但是彼此之间并无资源往来（进程之间不共享内存数据）；只是最终同属于一个老板（程序文件或者说主进程，父进程），老板不负责各个餐厅具体的事情，只负责
        管理每个餐厅的状态；

    多线程，单线程：
        我们其中有一家餐厅（一个进程），配了10个服务员（多线程），每来一个客人，就让一个服务员单独去服务这个客人，直到客人吃完
        离开后，这个服务员才空闲下来，因此我们的餐厅最高的并发就是10个客人同时进来吃饭；多余的客人则需要排队等待服务员空闲下来（线程阻塞）
        此时我们发现，进来一个客人（连接请求），就让一个服务员单独服务的开销太大，入不敷出，我们想假如只请一个服务员，一个客人进来，去服务客人点菜；
        点完菜后，继续服务下一个客人的点菜，烧菜交给厨师（另一个服务进程，如连接mysql，redis，IO操作）；等待烧菜完毕（如果不是异步，这里同样需要等待），我们的服务员再去把菜端给客人；完成这次服务后，继续服务下一个；
        此时的好处是，服务员一直处于工作状态，也不会阻塞了，同时开销也小了； 越来越赚钱了，很开心；
        但是缺点是，假如这个服务员奔溃了，撂挑子不干了，则导致整个餐厅也无法营业了（进程也奔溃了，即所有的请求都无法响应了）；

    高并发的冲击：
        某一天，我们想搞个促销打折活动，回馈客人，同时拉收一波；发了很多传单，吸引了大量客人，规定明天早上8点活动开启；
        此时到了第二天8点，同时100人进店点菜，但是此时我们只有一个服务员，尽管他只负责点菜，但是无赖客人太多，实在服务不过来，结果不过时，服务员奔溃了，不干了；
        此时大量的客人由于多长时间的等待和服务员无法回应，很多客人都骂骂咧咧的离开了餐厅； 

        之后，老板想，这样不行啊，举办一次活动，本来应该是皆大欢喜，咋还让我餐厅名誉变差了；营业额也差了；得想办法解决啊；
        于是老板又想，不就是一次活动客人突然增多吗，我如果加服务员应该能解决；于是老板又加到了之前得10个服务员；
        但是下一次活动，依然有问题，一次接纳的客人虽然变多了，但是同时100人进来，我们的餐厅座位只有20个啊（系统限制），
        于是老板动力动脑筋，改了改餐厅布局（修改了系统的某些限制参数），多塞了8个座位，但此时依旧无法应付一次几百人的涌入；怎么办?

        于是老板痛定思痛，下决定，再多开一个4~5个餐厅（多进程）， 此时每个配10个服务员，即此时，我们搞一次活动，最高并发能达到100~150，过了几天，
        老板发现，虽然这样能解决问题，但是开销很大啊，5个餐厅总共得配50个服务员，这也是一笔大开销，而且关键是高并发的时间并不多啊，
        于是老板再次改善思路，每个餐厅，只配一个服务员（多进程，单线程）；

后面，生意越来越好了，活动越来越多，越大，一次活动人数越来越多了，但是新的问题又来了，每个店子的一个服务员依旧忙不过来，经常撂挑子不干了，于是又加了服务员（多进程，多线程）；

但是此时，依然有新的问题（并发带来的数据问题），后续。。。。。。