小问题

[loyal_to]

恩，新人学了mvc知道怎么工作，有个小问题，求教下：
就是做了一个网站，发布出去，理论同一时间可以有无数个请求过来，网站是怎么处理这些请求的，是不是相当于用一个容器把这些请求储存起来，依次处理，返回信息给特定的IP，还是怎样

[loyal_to]

引用 3 楼 sp1234 的回复:

晕死！你看来是被java给绕晕了。 所谓用一个容器（或者说队列）存储起来依次处理，你信吗？你可以测试一下，一个用1秒钟处理的网页会不会阻塞一个用5毫秒处理的网页呢？不会的！所以所谓容器、队列的概念，只是一个很低级的技术概念，并不是高级的业务处理概念。任务是并发地被处理的，不管中间用了什么存储结构，最终还是要从这个存储结构中删除，而去“散列开”去并发处理。 在并发处理中，如果遇到访问共享的数据的情况需要同步，那么使用lock之类的语句可以让多线程（或者多进程）进入“管理区域”，同一时间只有一个线程（或者进程）执行这个区域中的代码。这在操作系统原理课程中会作为一个基本概念而讲到，在.net中你应该学会使用它。 总之，任务是并发的，并发的任务如果有个别一小块代码需要同步则可以使用lock。就是这个基本的知识点，而应该把多余的中间存储概念忘掉。

恩，大概意思是不是中间存储不关心，这些消息在线程池中并发散列开执行

[ajianchina]

不是依次处理，在设定的连接数范围内多线程并发处理。

[loyal_to]

引用 1 楼 ajianchina 的回复:

不是依次处理，在设定的连接数范围内多线程并发处理。

恩，那他开的线程数量是确定的，还是有一个连接就开一个线程 如果线程数量确定，就相当于还是在线程中存储数据依次处理？只是多了个切换线程？ 一个连接开一个线程，连接不会满吗？

[以专业开发人员为伍]

晕死！你看来是被java给绕晕了。 所谓用一个容器（或者说队列）存储起来依次处理，你信吗？你可以测试一下，一个用1秒钟处理的网页会不会阻塞一个用5毫秒处理的网页呢？不会的！所以所谓容器、队列的概念，只是一个很低级的技术概念，并不是高级的业务处理概念。任务是并发地被处理的，不管中间用了什么存储结构，最终还是要从这个存储结构中删除，而去“散列开”去并发处理。 在并发处理中，如果遇到访问共享的数据的情况需要同步，那么使用lock之类的语句可以让多线程（或者多进程）进入“管理区域”，同一时间只有一个线程（或者进程）执行这个区域中的代码。这在操作系统原理课程中会作为一个基本概念而讲到，在.net中你应该学会使用它。 总之，任务是并发的，并发的任务如果有个别一小块代码需要同步则可以使用lock。就是这个基本的知识点，而应该把多余的中间存储概念忘掉。

[以专业开发人员为伍]

引用 2 楼 loyal_to 的回复:

[quote=引用 1 楼 ajianchina 的回复:] 不是依次处理，在设定的连接数范围内多线程并发处理。

恩，那他开的线程数量是确定的，还是有一个连接就开一个线程 如果线程数量确定，就相当于还是在线程中存储数据依次处理？只是多了个切换线程？ 一个连接开一个线程，连接不会满吗？ [/quote] 高级的线程处理程序，不是分配什么线程对象，而是将Delegate注册给系统线程池中去执行。系统线程池会自动跟据CPU的统计状况而决定是否要延迟执行。在.net framework4.0中，对于32位应用，工作线程可以有1000多个、I/O线程也是1000多个；在64位系统应用中，工作线程可以有32000多个，I/O线程仍然是1000多个。 线程池不会随便创建新的线程，而是会复用线程。 注册给系统线程池的任务通常都应该迅速完成（例如几毫秒中）。如果你一下子注册了1万个任务，每个任务都需要10秒钟才能完成，那么肯定就是一个编程设计上的大 BUG了。

[以专业开发人员为伍]

要使用高级的系统线程池机制，就是写

ThreadPool.QueueUserWorkItem(h =>
{
    var a = 1;
    var b = a + 1;
});

这样的语句。而不是去写

new Thread(x =>
{
    var a = 1;
    var b = a + 1;
}).Start();

这样的语句。 虽然后者其实比前者快一点，但是如果你的程序是大量使用线程的，那么后者不能自动化地优化CPU利用，有可能产生产生拥塞——结果连简单的任务也执行不完。