基于fork和vfork函数都可以实现多进程并发服务器对吗？

是的，基于fork和vfork函数都可以实现多进程并发服务器。
使用fork函数创建新进程时，子进程会复制父进程的所有资源，包括程序代码、数据、堆栈等，然后在子进程中执行从fork函数开始的下一条语句。由于子进程与父进程是完全独立的，它们可以同时执行不同的任务，这就可以实现多进程并发。
使用vfork函数时，子进程并不会复制父进程的资源，而是与父进程共享同一块地址空间，直到子进程调用了exec或exit函数。因此，vfork函数比fork函数更加高效，但也更加危险，因为子进程可能会改变父进程的资源。
无论是使用fork还是vfork函数，都需要仔细设计进程之间的通信方式，以确保进程能够正确地协作工作，并避免竞争条件和死锁等问题。

问题一：java中怎么既能高并发效率又能线程安全 总的结论：java是线程安全的，即对任何方法（包括静态方法）都可以不考虑线程冲突，但有一个前提，就是不能存在全局变量。如果存在全局变量，则需要使用同步机制。
如下通过一组对比例子从头讲解：
在多线程中使用静态方法会发生什么事？也就是说多线程访问同一个类的static静态方法会发生什么事？是否会发生线程安全问题？
public class Test {
public static void operation(){
do something
}
}
事实证明只要在静态函数中没有处理多线程共享数据，就不存在着多线程访问同一个静态方法会出现资源冲突的问题。下面看一个例子：
public class StaticThread implements Runnable {
@Override
public void run() {
TODO Auto-generated method stub
StaticActionprint();
}
public static void main(String[] args) {
for (int i = 0; i 问题二：多线程并发处理，线程同步的含义和处理方法是一样的吗？ 你的这个问题这么久没人回答，我估计是因为大家觉得有点宽泛。我仅针对你提到的点解释一下。
要产生并发的效果，自然考虑的是多线程，甚至多进程。在并发的情况下，同步问题是一个常见的，或者在大多数情况都需要考虑的问题。而不是并发处理的一个方法。同步最简单直接的方式就是加锁。当然，根据你的情况不同还可能有多种的处理方式。这个需要具体问题具体分析。不知道能否解开你的疑惑。

问题三：如何解决多进程或多线程并发的问题 使用共享锁LOCK_SH，如果是读取，不需要等待，但如果是写入，需要等待读取完成。

使用独占锁LOCK_EX，无论写入/读取都需要等待。

LOCK_UN，无论使用共享/读占锁，使用完后需要解锁。

LOCK_NB，当被锁定时，不阻塞，而是提示锁定。

问题四：java多线程并发去调用一个类的静态方法，会有问题吗？ 并发能处生问题的情况是，两个线程都去竞争同一个对象才会产生问题，如果你的静态方法只是简单的逻辑是不会有问题的，但是如果你的线程都是去修改静态变量的值的话，应该是会造成线程问题的

问题五：什么时候处理多线程，几种方式，优缺点 呵呵 想理解多线程你就得 搞清楚什么是并发 什么是并行 ，概念：在单CPU系统中，系统调度在某一时刻只能让一个线程运行，虽然这种调试机制有多种形式(大多数是时间片轮巡为主)，但无论如何，要通过不断切换需要运行的线程让其运行的方式就叫并发(concurrent)。而在多CPU系统中，可以让两个以上的线程同时运行，这种可以同时让两个以上线程同时运行的方式叫做并行(parallel)。我也有段时间纠结于这里，无论如何我必须得给你明确一点：在某一个时间点，一个CPU（单）只会运行某一个进程里的单个线程，所以我们经常称之为并发，说道同步机制，其实多线程并未真正实现微观意义上的同步，进程是一个运行单元，线程则是更小的运行单元，简而言之，就是进程细分成多个线程，譬如：一个进程A运行需要1s，它就会切换到进程B，但是实现多线程机制后，进程A细化成10个线程，每个线程只需运行01s，当然B线程也一样，这就出现，线程之间的切换时间更短，从宏观上看就出现同步幻象了。所以学习多线程你得真正理解所谓的同步并发，并不是真正的“同步”。当你理解这些的时候，你就初略的感觉什么时候该使用多线程机制，其实你的电脑每个程序都至少有一个主线程，那个管理器中的每一个进程，其实内部包含若干线程，每个时间点都是某个程序进程中的某个线程在运行。这些都是我的理解 ，还有不懂的请继续提出，我会尽量帮你解答。

问题六：多线程并发服务器的缺点是什么？可采用什么克服 多线程处理的优点
同步应用程序的开发比较容易，但由于需要在上一个任务完成后才能开始新的任务，所以其效率通常比多线程应用程序低。如果完成同步任务所用的时间比预计时间长，应用程序可能会不响应。多线程处理可以同时运行多个过程。例如，文字处理器应用程序在您处理文档的同时，可以检查拼写（作为单独的任务）。由于多线程应用程序将程序划分成独立的任务，因此可以在以下方面显著提高性能：
多线程技术使程序的响应速度更快，因为用户界面可以在进行其他工作的同时一直处于活动状态。
当前没有进行处理的任务可以将处理器时间让给其他任务。
占用大量处理时间的任务可以定期将处理器时间让给其他任务。
可以随时停止任务。
可以分别设置各个任务的优先级以优化性能。
是否需要创建多线程应用程序取决于多个因素。在以下情况下，最适合采用多线程处理：
耗时或大量占用处理器的任务阻塞用户界面 *** 作。
各个任务必须等待外部资源（如远程文件或 Internet 连接）。
例如，用于跟踪 Web 页上的链接并下载满足特定条件的文件的 Internet 应用程序“robot”。这种应用程序可以依次同步下载各个文件，也可以使用多线程同时下载多个文件。多线程方法比同步方法的效率高很多，因为即使在某些线程中远程 Web 服务器的响应非常慢，也可以下载文件。
cachebaidu/aidu#0
下面是多线程的例子
还在Dos时代，人们就在寻求一种多任务的实现。于是出现了TSR类型的后台驻留程序，比较有代表性的有Side Kick、Vsafe等优秀的TSR程序，这类程序的出现和应用确实给用户使用计算机带来了极大的方便，比如Side Kick，我们编程可以在不用进编辑程序的状态下，一边编辑源程序，一边编译运行，非常方便。但是，Dos单任务 *** 作系统的致命缺陷注定了在Dos下不可能开发出真正的多任务程序。进入Windows31时代，这种情况依然没有根本的改变，一次应用只能做一件事。比如数据库查询，除非应用编得很好，在查询期间整个系统将不响应用户的输入。
进入了Windows NT和Windows 9x时代，情况就有了彻底的改观， *** 作系统从真正意义上实现了多任务（严格地说，Win9x还算不上）。一个应用程序，在需要的时候可以有许多个执行线程，每个线程就是一个小的执行程序， *** 作系统自动使各个线程共享CPU资源，确保任一线程都不能使系统死锁。这样，在编程的时候，可以把费时间的任务移到后台，在前台用另一个线程接受用户的输入。对那些对实时性要求比较高的编程任务，如网络客户服务、串行通信等应用时，多线程的实现无疑大大地增强了程序的可用性和稳固性。>>

问题七：java 多线程的并发到底是什么意思？ zhidao弧baidu/question/299404186&oldq=1

多线程是使用相同对象还是不同对象是由你的程序决定的，并不是由多线程技术决定的。
你传给线程对象哪个对象他就使用哪个。

问题八：Java多线程-并发的问题？ 5分 首先你发出一个请求就对应了一个线程。那么如你说的ssh中是线程安全的么
当然不是，他确实存在线程安全问题。但是为什么我们使用的时候没有问题呢，因为spring管理的整个项目，他帮我们做好了处理，我们不需要去关心线程问题，只要我们不去使用全局变量就没问题，如果想了解spring如果管理的话，你可以去百度，上边有详细讲解。
另外在说一句，做web其实对多线程的要求挺低的，有用也很少，做后台进程应该会多些

问题九：java多线程并发的问题 回答这个问题需要先弄清楚线程的概念和线程的生命周期。

线程：是指程序代码的一次执行，是动态的过程。楼主在定义OneTh这个实现Runnable接口类的时候肯定复写了他的run()方法。onet1和onet2是两个线程，也就是说虽然他们的run()方法相同，但是是执行了两次的。

计算机中CPU的调度过程：现在的电脑看上去能同时实现多任务，像是一边上QQ，一边听音乐，还可以一边上网。但计算机中的CPU只有一个，它没有分身术，不可能真正意义上实现同时运行这么多程序。而是采用了一种时间片轮转的方式，为每个应用程序赋予极短的时间，然后高速的在不同的程序间切换，至于每次切换到那个程序，这个要由CPU和线程的优先级来决定。

线程的生命周期：创建时是初始化了这个线程，调用start方法时，是让这个线程进入了可运行状态，注意是可运行，不是正在运行。就像上面说的，在某一时刻CPU具体要运行谁是由CPU和线程的优先级决定的。当线程被CPU运行时，就会开始执行run方法，但可能执行到一半时，CPU又被其他可运行线程抢走，而只能暂停执行。

JAVA程序线程的运行:在我们使用java命令来运行程序时，这时候已经开始了两个线程，一个是main()方法的线程，一个是垃圾回收的线程。当楼主调用start方法开启另外两个线程时。这时候由于CPU来决定运行哪个线程。所以虽然noet1是先开启的，但在执行noet1时，CPU可能又去跑去执行main线程了，然后就会开启onet2

还有我觉得主线程结束了，只不过其他两个线程仍在继续运行。所以会打印出结果。

楼主如果还有什么不明白的话可以继续问或者相互讨论。

问题十：java什么是线程并发怎么解决 并发是多个任务同时执行，在java中是通过多线程实现的。你想问的是如何安全地并发访问临界资源吧，在java中一般通过加锁来保证。

在java5以前实现多线程有两种方法（继承Thread类和实现Runnable接口）
它们分别为：
使用new Thread()和new Thread(Runnable)形式
第一种直接调用thread的run方法，所以，往往使用Thread子类，即new SubThread()。
第二种调用
Runnable的run方法。
第一种：
new Thread(){}start();这表示调用Thread子类对象的run方法，new Thread(){}表示一个Thread的匿名子类的实例对象，子类加上run方法后的代码如下：
new Thread(){
public void run(){
}
}start();
第二种：
new Thread(
new Runnable(){}
)start();
这表示调用Thread对象接受的Runnable对象的run方法，new Runnable(){}表示一个Runnable的匿名子类的实例对象,
runnable的子类加上run方法后的代码如下：
new Thread(new Runnable(){
public void run(){
}
}
)start();

大家都知道各类网络服务器程序的编写步骤，并且都知道网络服务器就两大类：循环服务和并发服务。这里附上源代码来个小结吧。
一、 循环服务
循环网络服务器编程实现的步骤是这样的：
建立socket（这里用到socket()函数及函数setsockopt()）
|
|
\|/
把socket和IP地址及端口绑定（这里用到bind函数）
|
|
\|/
开始监听（这里用到listen()函数）
|
|
/\
/ \
\ / \
----------------------- | 有连接|
| / \ /
| \ /
| \ /
| |
| 接受新的连接（这里用到accept()函数）
| | /___________________________________________________
| | \ |
| \|/ |
| 从连接里读取数据（这里用到recv()系统函数，当然也可以是read()函数） |
| | |
| | |
| \|/ |
| 返回信息给连接（这里用到send()系统函数，当然也可以是write()函数） |
| | |
| | |
| /\ |
| / \ |
| / \ |
| | 还有数据 |-Y-------------------------------------------------------
| \ /
| \ /
| \ /
|_______________________________|
这种服务器模型是典型循环服务，如果不加上多进程/线程技术，此种服务吞吐量有限，大家都可以看到，如果前一个连接服务数据没有收发完毕后面的连接没办法处理。所以一般有多进程技术，对一个新连接启用一个新进程去处理，而监听socket继续监听。
/

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 *** 作数据。这样在数据传输过程中不需要用户线程的介入，减少了数据被拷贝的次数，减少了上下文切换的开销。

服务器创建并绑定套接字后fork出几个子进程，子进程中分别进行accept（该函数为阻塞函数）、recv、处理数据然后再次acept，这样循环下去。所有客户端发来的信息都是直接由子进程处理。
例程
代码如下，在处理客户端请求之前，服务器先fork了3个子进程，然后将客户端的请求直接交由子进程处理。
该例程中，服务器fork子进程后，子进程监听并接收客户端的信息，然后打印客户端发来的信息和自己的id（id代表自己是第几个子进程）
服务器端代码：
/
author:arvik
purpose:test the server simultaneity
email:1216601195@qqcom
csdn: >有多个 CPU 可用。单核机器上多线程的优势不明显。
线程间有共享数据。如果没有共享数据，用模型 3b 就行。虽然我们应该把线程间的共享数据降到最低，但不代表没有；
共享的数据是可以修改的，而不是静态的常量表。如果数据不能修改，那么可以在进程间用 shared memory，模式 3 就能胜任；
提供非均质的服务。即，事件的响应有优先级差异，我们可以用专门的线程来处理优先级高的事件。防止优先级反转；
latency 和 throughput 同样重要，不是逻辑简单的 IO bound 或 CPU bound 程序；
利用异步 *** 作。比如 logging。无论往磁盘写 log file，还是往 log server 发送消息都不应该阻塞 critical path；
能 scale up。一个好的多线程程序应该能享受增加 CPU 数目带来的好处，目前主流是 8 核，很快就会用到 16 核的机器了。
具有可预测的性能。随着负载增加，性能缓慢下降，超过某个临界点之后急速下降。线程数目一般不随负载变化。
多线程能有效地划分责任与功能，让每个线程的逻辑比较简单，任务单一，便于编码。而不是把所有逻辑都塞到一个 event loop 里，就像 Win32 SDK 程序那样。

---