多线程多进程使用场景（编程中什么时候使用多线程）

本文目录

• 编程中什么时候使用多线程
• Linux 下多线程和多进程程序的优缺点，各自适合什么样的业务场景
• Linux下多线程和多进程程序的优缺点，各个适合什么样的业务场景
• 怎么理解并发多进程服务和多线程服务器

编程中什么时候使用多线程

多线程的使用主要是用来处理程序“在一部分上会阻塞”，“在另一部分上需要持续运行”的场合。一般是根据需求，可以用多线程，事件触发，callback等方法达到。但是有一些方法是只有多线程能办到的就只有用多线程或者多进程来完成。
举个简单的例子，能理解就行。假设有这样一个程序，
1会不停的处理收到的所有TCP请求。对于每个TCP请求做不同的操作。不能有遗漏
2有很多特定的请求会向一个服务器发送存储的数据，或者是等待用户输入。

来看看。第1个要求很简单。用个while循环就搞定了。但第2个特性呢。一旦在等待用户输入或者是连接服务器时，程序会“阻塞”一段时间，这一段时间内就无法处理其他的TCP请求了。
所以可以利用多线程，每个线程处理不同的TCP请求。这样程序就不会“阻塞”掉了。

Linux 下多线程和多进程程序的优缺点，各自适合什么样的业务场景

Linux 下多线程和多进程程序的优缺点，各自适合什么样的业务场景
　　IBM有个家伙做了个测试，发现切换线程context的时候，windows比linux快一倍多。进出最快的锁（windows2k的 critical section和linux的pthread_mutex），windows比linux的要快五倍左右。当然这并不是说linux不好，而且在经过实际编程之后，综合来看我觉得linux更适合做high performance server，不过在多线程这个具体的领域内，linux还是稍逊windows一点。这应该是情有可原的，毕竟unix家族都是从多进程过来的，而 windows从头就是多线程的。
　　如果是UNIX/linux环境，采用多线程没必要。
　　多线程比多进程性能高？误导！
　　应该说，多线程比多进程成本低，但性能更低。
　　在UNIX环境，多进程调度开销比多线程调度开销，没有显著区别，就是说，UNIX进程调度效率是很高的。内存消耗方面，二者只差全局数据区，现在内存都很便宜，服务器内存动辄若干G，根本不是问题。
　　多进程是立体交通系统，虽然造价高，上坡下坡多耗点油，但是不堵车。
　　多线程是平面交通系统，造价低，但红绿灯太多，老堵车。
　　我们现在都开跑车，油（主频）有的是，不怕上坡下坡，就怕堵车。
　　高性能交易服务器中间件，如TUXEDO，都是主张多进程的。实际测试表明，TUXEDO性能和并发效率是非常高的。TUXEDO是贝尔实验室的，与UNIX同宗，应该是对UNIX理解最为深刻的，他们的意见应该具有很大的参考意义。

Linux下多线程和多进程程序的优缺点，各个适合什么样的业务场景

多进程比较安全，因为默认情况下不同进程之间的内存是独立的（如果需要共享内存则需要进行进程间通信）。而多线程下，内存是共享的，这时就比较危险了，你要自己使用锁、信号量等机制来解决内存块的同时读写和同步等等。如果两个功能没有数据需要共享，或只有前后递进关系，建议使用多进程。如果两个功能需要同时对一块数据进行处理（例如需要对资源进行创建和老化删除），则需要使用多线程，这时可能需要使用锁等机制来控制线程冲突。

怎么理解并发多进程服务和多线程服务器

1，进程：子进程是父进程的复制品。子进程获得父进程数据空间、堆和栈的复制品。
2，线程：相对与进程而言，线程是一个更加接近与执行体的概念，它可以与同进程的其他线程共享数据，但拥有自己的栈空间，拥有独立的执行序列。
两者都可以提高程序的并发度，提高程序运行效率和响应时间。
线程和进程在使用上各有优缺点：线程执行开销小，但不利于资源管理和保护；而进程正相反。同时，线程适合于在SMP机器上运行，而进程则可以跨机器迁移。
答案二:
根本区别就一点：用多进程每个进程有自己的地址空间(address space)，线程则共享地址空间。所有其它区别都是由此而来的：
1。速度：线程产生的速度快，线程间的通讯快、切换快等，因为他们在同一个地址空间内。
2。资源利用率：线程的资源利用率比较好也是因为他们在同一个地址空间内。
3。同步问题：线程使用公共变量/内存时需要使用同步机制还是因为他们在同一个地址空间内。

网上的答案的 版本怎么想怎么都太学术了。我当时看到过一个比喻特别的好， 我就模仿者把它说下来哈，有错误希望支持哈：
多进程的服务器就好比是
立体的交通系统（立交桥）虽然说建造的时候花费比较大，消耗的资源比较多，但是真要是跑起来不会交通堵塞。但是汽车在上面跑，相互通信就是个很费事儿问题（进程间通信比较麻烦）；多线程就好比是平面的交通系统，造价低，但是很容易交通堵塞，
但是也有好处同步的时候方便。
在网络服务器方面：
单进程 《 多进程(单线程)《 多进程（多线程）
在游戏方面的应用：
I、多线程服务器，玩家数据缓存和向DB的存储我们可以开一个线程单独去做，这样不会有什么大的问题。日志和网络上面说过可以很容易切割出去，主要就是对游戏逻辑的切割。
A：按场景分线程，一个线程管理若干个场景。这样配置灵活，一个线程可以管理若干个小场影，除非有个场景人多到一个CPU跑不下来，一般的游戏都会满足需求。缺点则是不在同一线程的Object在做逻辑交互时，必须用异步，如果用到了脚本，那么这里的复杂度和性能要值得注意。如果项目中出现单个服务器解决不鸟的问题(例如战场服务器)，似乎就成了多线程多进程的庞大架构。
B：将某些功能切割到其它线程，例如Object的管理和查找，NPCAI的寻路，这种方式貌似在做逻辑需要分离到别的线程模块功能时有点麻烦，如果直接上锁等待肯定不是最好的方式,所以这些逻辑必须变成异步。
2、多进程服务器,其实这里的多进程和场景多线程改成了多进程。这里玩家数据缓存和向DB的存储我觉得用一个单独的DB服务器。多进程服务器可以在GameServer和GameClient之间加一个Gate，因为在跨服场景不需频繁断线连接。多进程服务器所有的通讯都依靠网络，有些逻辑必须有网络延迟的消耗。优点是配置灵活，在物理机器性能不够时可以通过扩充物理机器来解决
服务器还有有一个很蛋疼的问题就是过载： 下面介绍一下产生的原因和解决办法：
服务器过载：
原因是高优先级处理阶段对CPU的不公平抢占。所以，如果限制高优先级处理阶段对CPU的占用率，或者限制处理高优先级的CPU个数，都可以减轻或者消除收包活锁现象。具体的可以采用以下的方法：
方法一、采用轮询机制
为了减少中断对系统性能的影响，在负载正常的情况下采用“下半处理”的方法就非常有效，而在高负荷情况下，采用这个方法仍然会造成活锁现象，这时可以采用轮询机制。虽然这个方法在负载正常的情况下会造成资源的浪费和响应速度降低，但在网络数据频繁到达服务器时就要比中断驱动技术有效的多。
方法二、减低中断的频率
这里主要有两种方法：批中断和暂时关闭中断。批中断可以在超载时有效的抑制活锁现象，但对服务器的性能没有什么根本性的改进;当系统出现接收活锁迹象时，可以采用暂时关闭中断的方法来缓和系统的负担，当系统缓存再次可用时可以再打开中断，但这种方法在接收缓存不够大的情况下会造成数据包丢失。
方法三、减少上下文切换
这种方法不管服务器在什么情况下对性能改善都很有效，这时可以采用引入核心级(kerne1—leve1)或硬件级数据流的方法来达到这个目的。核心级数据流是将数据从源通过系统总线进行转发而不需要使数据经过应用程序进程，这个过程中因为数据在内存中，因此需要CPU操作数据。
硬件级数据流则是将数据从源通过私有数据总线或是虽等DMA通过系统总线进行转发而不需要使数据经过应用程序进程，这个过程不需要CPU操作数据。这样在数据传输过程中不需要用户线程的介入，减少了数据被拷贝的次数，减少了上下文切换的开销。