linux server 到底单线程还是多线程？ - 简书
linux server 到底单线程还是多线程？
1.高并发，大吞吐量的标准服务器，比如 HaProxy, Lighttpd
一般采用单线程事件驱动的方式开发。2.偏向业务，cpu计算型，如 memcached，一般采用多线程事件驱动方式开发。本质是为了提高响应度。./pingpong_server ip,port thread_num./pingpong_client ip,port thread_num,message_num,connect_num,timeout单线程和多线程的简单理解 - 简书
单线程和多线程的简单理解
线程：简单的说就是处理事务的任务链，当只有一条链，所有的事情都在这一条链上执行时，那就是单线程，单线程有很多缺点，就是当执行某个耗时或者不能立即完成的任务时，比如：网络通讯、复杂运动，该线程就会暂时停止对其他任务的响应和处理，造成的视觉效果就是程序的“假死”，也就是应用程序被卡在那里无法继续执行，因此在多数情况下，单线程的应用很少。而当有多条链时，那就是多线程了，当然并不是说多条线并行，而是说有一条主线程，处理整个程序任务的主方向的链，而其链上又有许许多多的分支，就像树枝那样，这样，既有了主线程去处理那些主要任务，又有了那些细小线程去处理耗时费力任务，从而让界面看起来更加流畅。iOS平台对多线程的支持iOS平台提供了非常优秀的多线程支持，程序可以通过非常简单的方式来启动多线程，iOS平台不仅提供了NSThread类来创建多线程，还提供了GCD方式来简化多线程编程，提供了NSOperation和NSOperationQueue支持多线程编程。线程和进程几乎所有的操作系统都支持同时运行多个任务，一个任务通常就是一个程序，每个运行中的程序就是一个进程。
当一个程序运行时，内部可能包含了多个顺序执行流，每个顺序执行流就是一个线程。几乎所有的操作系统都支持进程的概念，所有运行中的任务通常对应一个进程(Process)。当一个程序进入内存，运行后，即变成一个进程。**进程是处于运行过程中的程序，并且具有一定的独立功能，进程是系统进行资源分配和调度的一个独立单位**。一般而言，进程包含如下3个特征：
- 独立性：进程是系统中独立存在的实体，它可以拥有自己独立的资源，每一个进程都拥有自己私有的地址空间。在没有经过进程本身允许的情况下，一个用户进程不可以直接就访问其他进程的地址空间。 - 动态性：进程与程序的区别在于，程序只是一个静态的指令集合，而进程是一个正在系统中活动的指令集合。在进程中加入了时间的概念。进程具有自己的生命周期和各种不同的状态，这些概念在程序中都是不具备的。
- 并发性：多个进程可以在单个处理器上并发执行，多个进程之间不会互相影响。并发性(concurrency)和并行性(parallel)是两个不同的概念。并行指在同一时刻，有多条指令在多个处理器上同时执行；并发指在同一时刻，只能有一条指令执行，但多个进程指令被快速轮换执行(纳秒级)，使得在宏观上具有多个进程同时执行的效果。
大部分操作系统都支持多进程并发运行，现代的操作系统几乎都支持同时运行多个任务对于一个CPU而言，它在某个时间点上只能执行一个程序，也就是说，只能运行一个进程，CPU不断地在这些进程之间轮换执行。为什么感觉不到任何中断现象？这是因为CPU的执行速度相对人类的感觉而言是在是太快了。当然，如果启动的程序足够多，依然可以感觉到程序的运行速度下降。所以虽然CPU在多个进程之间轮换执行，但感觉到(宏观上)好像多个进程在同时执行。现代的操作系统都支持多进程的并发(轮换执行)，但在具体的实现细节上可能因为硬件和操作系统的不同而采用不同的策略。目前操作系统大多采用效率更高的抢占式多任务策略，例如WindowsNT、windows2000以及UNIX/Linux等操作系统。多线程则扩展了多进程的概念，使得同一个进程可以同时并发(轮换执行)处理多个任务。线程(Thread)也被称作轻量级进程(LightweightProcess)，线程是进程的执行单元。就像进程在操作系统中的地位一样，线程在进程中是独立的、并发的执行流。进程操作系统--线程进程当进出被初始化后，主线程就被创建了对于应用程序而言，通常至少有一个主线程，可以在该进程内创建多条顺序执行流，这些顺序执行流就是线程，每条线程也是相互独立的；线程是进程的的组成部分，一个进程可以拥有多个线程，一个线程必须有一个父进程，线程可以拥有自己的堆栈、自己的程序计数器和自己的局部变量，但是不再拥有系统资源，它与父进程的其他线程共享该进程所拥有的全部资源。因为多个线程共享父进程里的全部资源，因此编程更加方便；但必须更加小心，必须确保线程不会妨碍同一进程里的其他线程。
线程可以完成一定的任务，可与其他线程共享父进程中的共享变量及部分环境，相互之间协同来完成进程所要完成的任务；
线程是独立运行的，它并不知道进程中是否还有其他线程存在。线程的执行是抢占式的，也就是说，当前运行的线程在任何时候都可能被挂起，以便另一个线程可以运行；
一个线程可以创建和撤销另一个线程，同一个进程中的多个线程之间可以并发执行；
从逻辑角度看，多线程存在于一个运行中的应用程序中，让一个运行中的应用程序中可以有多个执行部分同时执行(宏观上)，但操作系统无须将多个线程看作多个独立的应用，对多线程实现调度和管理以及资源分配。线程的调度和管理由进程本身负责完成。简而言之，一个程序运行后至少有一个进程，一个进程里至少要包含一个线程(即主线程)，可以包含多个线程。操作系统可以同时执行多个任务，每个任务就是进程；进程可以同时执行多个任务，每个任务就是线程。多线程线程在运行中的程序中是独立的、并发的执行流，与分隔的进程相比，进程中的线程之间的隔离程序要小，因为它们共享内存、文件句柄和其它每个进程应有的状态。
因为线程的划分尺度小于进程，使得多线程程序的并发性高。进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率。线程比进程具有更高的性能：这是因为同一个进程中的线程都有共性——多个线程将共享同一个进程虚拟空间。线程共享的环境包括：进程代码段、进程的公有数据等。利用这些共享的数据等，线程很容易实现相互之间的通信。当操作系统创建一个进程时，必须为该进程分配独立的内存空间，并分配大量的相关资源；但创建一个线程则简单很多，因此使用多线程来实现并发比使用多进程实现并发的性能要高得多。使用多线程编程具有如下优点：
进程之间不能共享内存，但同一进程中的线程之间共享内存非常容易；
系统创建进程需要为该进程重新分配系统资源，但创建线程则代价小得多，因此使用多线程来实现多任务并发比多进程的效率高；2015年11月 扩充话题大版内专家分月排行榜第一2015年7月 扩充话题大版内专家分月排行榜第一2015年1月 扩充话题大版内专家分月排行榜第一2014年9月 扩充话题大版内专家分月排行榜第一(补)2013年9月 扩充话题大版内专家分月排行榜第一2013年8月 扩充话题大版内专家分月排行榜第一2013年7月 扩充话题大版内专家分月排行榜第一
2016年3月 扩充话题大版内专家分月排行榜第二2015年12月 扩充话题大版内专家分月排行榜第二2015年6月 扩充话题大版内专家分月排行榜第二2015年2月 扩充话题大版内专家分月排行榜第二2014年10月 扩充话题大版内专家分月排行榜第二2014年8月 扩充话题大版内专家分月排行榜第二
2013年6月 Linux/Unix社区大版内专家分月排行榜第二2013年5月 Linux/Unix社区大版内专家分月排行榜第二2013年3月 Linux/Unix社区大版内专家分月排行榜第二2013年1月 Linux/Unix社区大版内专家分月排行榜第二2012年12月 Linux/Unix社区大版内专家分月排行榜第二2012年8月 Linux/Unix社区大版内专家分月排行榜第二2011年12月 Linux/Unix社区大版内专家分月排行榜第二2011年10月 C/C++大版内专家分月排行榜第二2011年10月 Linux/Unix社区大版内专家分月排行榜第二
2012年6月 C/C++大版内专家分月排行榜第三2012年6月 PHP大版内专家分月排行榜第三2012年5月 C/C++大版内专家分月排行榜第三2012年3月 Linux/Unix社区大版内专家分月排行榜第三2012年2月 Linux/Unix社区大版内专家分月排行榜第三2011年11月 C/C++大版内专家分月排行榜第三
2013年6月 Linux/Unix社区大版内专家分月排行榜第二2013年5月 Linux/Unix社区大版内专家分月排行榜第二2013年3月 Linux/Unix社区大版内专家分月排行榜第二2013年1月 Linux/Unix社区大版内专家分月排行榜第二2012年12月 Linux/Unix社区大版内专家分月排行榜第二2012年8月 Linux/Unix社区大版内专家分月排行榜第二2011年12月 Linux/Unix社区大版内专家分月排行榜第二2011年10月 C/C++大版内专家分月排行榜第二2011年10月 Linux/Unix社区大版内专家分月排行榜第二
2012年6月 C/C++大版内专家分月排行榜第三2012年6月 PHP大版内专家分月排行榜第三2012年5月 C/C++大版内专家分月排行榜第三2012年3月 Linux/Unix社区大版内专家分月排行榜第三2012年2月 Linux/Unix社区大版内专家分月排行榜第三2011年11月 C/C++大版内专家分月排行榜第三
2013年 总版技术专家分年内排行榜第三
2012年 总版技术专家分年内排行榜第七
本帖子已过去太久远了，不再提供回复功能。问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
昨天在浏览一篇文章的时候，发现文章中有这么一句话：
（3）便于建模。假设有一个大的任务A，单线程编程，那么就要考虑很多，建立整个程序模型比较麻烦。但是如果把这个大的任务A分解成几个小任务，任务B、任务C、任务D，分别建立程序模型，并通过多线程分别运行这几个任务，那就简单很多了。
我对此表示难以理解，并且在回复中与作者展开了热烈的讨论，但似乎我们谁都无法说服谁。在我看来事情是很明白的，多线程的复杂度肯定是大于等于单线程的复杂度的，但作者却说多线程更简单。所以在这里提问，想了解一下各位的看法。
下面是我和作者“讨论/争论”的内容：
（我）这个讲反了吧。单线程的才简单，只是效率低；多线程会大幅度增加代码复杂度，但是会提高效率
（作者）我举个例子吧，比方说一个支付系统，它要完成三项工作：1、根据用户的订单后台扣费 2、发送短信给用户提示用户消费成功 3、在某张表中记录用户此次消费行为，以便分析用户的消费习惯，引导用户消费，这是大数据时代会常做的一件事假如说这三项工作每项工作都包含很多细节，放在单线程里面操作，那么这条线程要考虑的内容就非常多，整个代码流程会变得很复杂如果我是用多线程就不一样了，我完全可以将此次的行为划分为三部分任务：1、扣费任务 2、发短信任务 3、记录用户消费任务。每部分任务一条线程执行，只需要保证发短信任务和记录用户消费任务在用户扣费任务成功之后就可以了。这三项任务可以分别交由三个不同的开发者进行开发，由于将一个大的任务拆分成了几个小的任务，因此对每部分小任务来说建模、整理流程就变得简单了。再举个例子来说，一条线程统计C盘、D盘、E盘总共三个磁盘的内存大小，和三条线程分别统计C盘、D盘、E盘三个磁盘的大小并交由另一条线程进行汇总，明显后面的写起来会比前面的容易吧。你说的单线程简单、多线程复杂，是从底层实现角度来说的，因为多线程需要考虑诸如线程切换这种问题，非常复杂，但是这个Java虚拟机已经帮助开发者实现好了。我说的单线程复杂、多线程简单，是从应用层角度来说的，大任务划分为小任务，便于开发和团队协作
（我）我说的多线程复杂就是针对我们开发者来说的！你所举的两个例子。第一个例子，为什么使用多线程反而简单呢？扣费任务、发短信任务、记录用户消费任务，把这些任务写成3个函数难道比使用多线程复杂？使用多线程也至少要写3个函数吧（实际上是3个类！）？而且多线程之间需要同步，例如后面2个任务必须等到扣费完成以后吧，单线程3个函数完全不用同步，顺序执行即可。而且你也说了“只需要保证发短信任务和记录用户消费任务在用户扣费任务成功之后就可以了”，说明你也考虑到同步问题了，而线程的同步问题是最复杂的一类问题，没有简单的解决方案，尤其是具有复杂逻辑的多线程之间的同步，经常会导致同步失败，以及死锁问题。而你却说多线程简单！
第二个例子我就更难理解了，统计磁盘大小的程序，逻辑最简单的应该是在一个线程里面顺序调用函数进行统计吧？程序执行完了结果立即就出来了。
（作者）首先，你要知道Java应用如此广泛，有两点原因：1、面向对象 2、跨平台性。其中第二点是重点，第一点是次重点。你反复提到了函数，这首先就不符合面向对象的思路，面向对象分析针对的是对象，面向过程分析针对的才是函数。当然，很多问题，我们都可以用函数的思路去解决，A()--&B()--&C()，但这样，如果对于一个问题的思考，都从你说的"函数"角度出发，就失去了面向对象的特点，问题越大，就越增加了分析问题的复杂度。其次，你提到了同步，我当时没有把这个点讲清楚，实际上单线程编程才需要考虑同步，多线程根本就不需要考虑同步的问题。"只需要保证发短信任务和记录用户消费任务在用户扣费任务成功之后就可以了"，怎么保证？使用异步架构（也就是多线程），生产者/消费者模型的问题就可以了。每次扣费成功，往一个阻塞队列里面放一个数据，发短信任务、记录用户消费任务只需要往这个阻塞队列里面取数据就可以了，只要队列里面有数据，就表示这是处理成功的扣费任务，这样三个任务可以相互独立发展、不需要相互依赖，是不是就各自建模了呢？至于最后一段话，看得出来，你对这个问题的解读太简单了，"逻辑最简单的应该是在一个线程里面顺序调用函数进行统计吧"，这是典型的、纯粹的面向过程的想法，前面我已经提过了。说了这么多，总结两点：1、假如面向过程好，就不会有面向对象诞生。小问题面向过程方便，问题越大越需要使用面向对象的思路去分析问题。你的说法，都是建立在任务比较简单的前提下的，没有真正考虑到一个任务的复杂度 2、使用多线程，对大任务进行拆分，使用异步架构解耦，各自独立发展，便于建模，这是使用多线程的优势所在
（我）“单线程编程才需要考虑同步，多线程根本就不需要考虑同步的问题”，请问你是如何得出这么骇人听闻、惊天地泣鬼神的结论的？（没有讽刺的意思，这是我看到你这句话时的真实反应）。另外，我所说的函数和面向过程还是面向对象没有任何关系，无论是面向过程还是面向对象，最后都需要函数（方法）来处理事情，不是吗？你把我所说的单方面理解成面向过程是不对的，当然，也许是我没有说清楚。但这里我们讨论的重点不是这个。但是这里我要强调的一点是，无论是采用面向过程还是面向对象的方式，都与我们这里讨论的重点——多线程——没有任何关系。无论是面向对象也好，面向过程也罢，对你所举的例子来说，单线程无疑都是比多线程实现起来要更简单。实际上对于所有的例子都是如此，多线程的复杂度&=单线程的复杂度，在任何情况下都成立，而且通常都是大于，只有在特殊情况下才有可能等于（多个线程之间完全没有关系，是完全独立的）。最后，其他的我想我们不必再讨论了，毕竟不是你这篇文章的重点，以后有机会可以再交流。但是希望你能够就我开头所引用的那句话给予回复，为什么你会说“单线程编程才需要考虑同步，多线程根本就不需要考虑同步的问题”这种话呢？
（我）“使用多线程，对大任务进行拆分，使用异步架构解耦，各自独立发展，便于建模，这是使用多线程的优势所在”解耦有多种方法，没必要完全依赖于异步架构。另外你只考虑到解耦这一层，你考虑过异步架构的调试、排错和Bug重现吗？异步架构最容易出现的问题就是“幽灵Bug”，也就是那些偶尔出现一次，等到你真正想找出它的时候它可能死也不出现！但是放到生产环境之后保不住哪天又给你来几次，如果你真的对异步架构很了解，不可能不知道它的弊端吧？异步架构确实能够有效地在模块间解耦，但它是以增加复杂度为代价的。所以NodeJS采用异步架构的同时，将用户逻辑限定到单线程中，事实证明这是一种很好的策略！想一想如果NodeJS允许多线程会怎么样？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
简单看了下，貌似两者不在一个出发点，或者说说的压根不是一件事。单线程简单是简单在程序编写上，复杂在业务逻辑多线程简单是简单在通过分拆将复杂的业务逻辑分拆到多个简单的子任务，这个其实不是多线程的概念，LZ所说的作者有点跑偏了，单线程也是可以分拆呀。当然多线程的复杂就不用说了，同步、竞争要多麻烦有多麻烦。
自己的观点，有错欢迎点评
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
这还用讨论, 必然是单线程简单啊. 多线程带来的好处是, 很可能能提高系统的并发量或者吞吐量. 这里为什么用很可能能, 意思是, 很多时候都是妄想.比如我在做Server开发, 看到有一些人用多线程写逻辑, 实际上并不能提高系统的并发量和吞吐量. 反而使问题复杂化, 甚至有可能并行会退化到1, 可能还不如单线程程序.
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
我觉得看出发角度是什么，只能从开发难度跟性能中取舍
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
嗯，在你的推荐下看到了这个讨论内容，其实我觉得总体来说是明确的，我在这里总结下。
我说的多线程简单，单线程复杂：大任务拆分成小任务，对小任务建模、编码简单你说的多线程复杂，单线程简单：因为将系统应用在高并发下，多线程的方式将会出现很多难以预期的BUG，也难以定位、修改
我不认为大任务拆分成小任务非要使用多线程，单线程的方式也可以，只是我提出了一个观点：单线程拆分的逻辑太多，函数太多，就把面向对象编程编程了面向过程编程了，这并不符合Java语言的特点。
最后回到原文，因为那条的主题是"多线程的优点"，只要多线程的方式可以将大任务拆分成小任务，并且对小任务分别建模，那就可以印证那一条优点的正确性了。
说了这么多，关键还是我们讨论问题的出发点不一致，就像楼上说的，从出发点的角度考虑，在开发难度和性能间取舍。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
多线程从编程难度或者实现上是难得多的；
从建模复杂度上是是简单的，举个例子，如果没有使用多线程模型，你JavaWeb的那么多不同业务的Servlet用单线程又应该怎么写呢？
这一点你可以参考《Java Concurrency in Practice》，关于建模简单性是有提到的。
1.2.2 Simplicity of modeling...
同步到新浪微博
分享到微博？
你好！看起来你挺喜欢这个内容，但是你还没有注册帐号。 当你创建了帐号，我们能准确地追踪你关注的问题，在有新答案或内容的时候收到网页和邮件通知。还能直接向作者咨询更多细节。如果上面的内容有帮助，记得点赞 (????)? 表示感谢。
明天提醒我
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：