知道了一些

关注下

我想我会用缓存做。。

留爪

这是让我最为震撼的一张图片!!!!!!!!

我的做法是将计数器加载到缓存中，每访问一次累加。每24小时自动刷新数据库，当网站关闭时自动刷入数据库。

从页面上获取的访问量全是缓存中的，跟数据库中的一点关系也没有。 而在网站启动时延时加载计数。

@深山老林
旁边还有个日文版的啊。咯咯

@flyingchen
英文版的，阅读起来有些困难。

@flyingchen
谢了,研究研究

@flyingchen
呵呵,是会有这个问题..

最后推荐个东西tokyo(http://tokyocabinet.sourceforge.net/index.html)，做这个也很快。据文档上说0.7s一百万条记录插入。

最好不仅仅局限于时间，流利突增时还是有问题的。而且发生错误时怎么保证数据不丢失又不暴内存也需要考虑

缓冲区切换时还是需要同步一下的吧

@小菜菜
如果你需要，给我邮箱，我可以给你threadpool和smartthreadpool的测试代码，至于我自己写的，暂时不想公布出来，但我可以给你测试结果数据。
不建议使用threadpool的一个最大原因在上面我已经做说明了。

3.5 的thread pool 还有一个致命的缺陷，就是每次启动的处理线程只会有2个
好像是每1秒钟去启动一次，另外定义的最小线程数没有用，它不会按这个定义一开始启动相应的线程

@ITAres
你在设计一个组件的时候，注意力不要全部放在你设计的组件上，你还要考虑这个组件运行时是否会对其他工作产生影响，如果你的所有线程一直在做事而不去切换线程，那么其他的事情难道就不做了吗？在这种情况下，new thread基本不会start。当然往往任务会调用其他资源导致当前线程阻塞而切换出cpu，比如调用数据库，调用io，调用其他机器上的资源，都会导致阻塞，但你的组件应该考虑到任务没有任何阻塞的情况。

@tmxk2002
说的很有道理..谢谢

但是:
如果队列里有10w条任务在处理这10w条任务的时会去休眠吗？？

-------------有任务为什么还要休眠呢?可以指明一下吗?

@tmxk2002
请这位大侠公布一下您的测试程序，小的觉得默认tp在效率上不至于那么容易被击败~

自带的的确不好用，执行得太慢了。。。后来改成自己写的后一点问题也没了

WorkQueue.cs

在 nicpetshop 里有

--引用--------------------------------------------------
ITAres: @tmxk2002
1:加任务是主线程在加的,也就是说只有一个线程在加任务,没有什么线程安全的问题了.当然也要看具体应用了

3:while(true)里面是有sleep的.你认真看一下.

4:干脆一开始就启动maxthreadcount的线程--没任务你启动线程干嘛,要资源的啊.

5: _threadCount,_inUseWorkThread这两个变量是不一样的,你认真看一下.

---------------这只是一个初级版本,确实在很多地方需要改进.感谢你的指点.
--------------------------------------------------------


加任务是单线程的？那你这是什么线程池呢？你能保证外面调用你的组件是单线程调用的？除非你只是自己封装了一下自己用，那就不要贴到这个上面，万一哪个人copy了你的代码去用，那不害惨他了？

你的sleep是在if (workItem == null)的情况下才发生，如果队列里有10w条任务在处理这10w条任务的时会去休眠吗？？

如果你的这个线程池使用信号量，启动最大线程以后通过信号量来阻塞，会耗什么资源呢？你没测试过start 线程也是一个耗资源的动作，它要分配cpu分配寄存器资源，要让操作系统重新计算调度数据，你频繁的启动线程，损耗的是内核资源知道不？

你的变量是不一样，但我说的不是变量不一样的问题，是说的变量会被脏读的问题，这种脏读会导致判断不准而出现偏差


既然把你的东西贴到博客上来了，要么把使用它的前提条件说清楚，要么就写的精细点，技术可是个严谨的活，不然你写博客干什么呢？让别人学习你的粗糙的功底？？

@hs0014
这只是一个很简单的功能,以后会持续改进.

@tmxk2002
1:加任务是主线程在加的,也就是说只有一个线程在加任务,没有什么线程安全的问题了.当然也要看具体应用了

3:while(true)里面是有sleep的.你认真看一下.

4:干脆一开始就启动maxthreadcount的线程--没任务你启动线程干嘛,要资源的啊.

5: _threadCount,_inUseWorkThread这两个变量是不一样的,你认真看一下.

---------------这只是一个初级版本,确实在很多地方需要改进.感谢你的指点.

写得不错，关注任务管理，以及线程的任务分配算法等功能

--引用--------------------------------------------------
Jeffrey Zhao: 其实.NET自带的线程池效率很高，经过很大调整和优化的，一般实现都比不过它。
如果不是有绝对的“违背”，只要封装一下ThreadPool就可以了，比如负载均衡，任务取消都可以实现，MSDN Magazine中有一个系列谈了很多这方面的问题，可以一看。
--------------------------------------------------------
很遗憾，前短时间我写的一个就比它快多了。前段时间正好研究了这个，包括smartthreadpool，对这几个都测试比较了，本身的threadpool确实比smartthreadpool快。

最后说过郁闷的事情，lz的文章怎么全是代码就可以放在首页，而我的就不可以呢？博客园是不是欺负新来的啊~~~

另外有人在问为什么不直接使用v.net的threadpool，再次用我的方式解释下。

大家应该知道每个进程只会有一个threadpool,也就是说如果你再用threadpool，那么别人写的代码也可能在用threadpool，因为一个进程的代码可能包括多个模块，而这些模块可能由不同的人开发的，而线程池事实上是用一个队列来隔离请求与处理的，那么大家就都往这个队列里压入workcallback，好了，队列就变得越来越庞大，后面进来的workcallback就在那里等着吧。这还好，最要命的就是v.net本身很多多线程处理的任务也是用的threadpool，比如wcf，那么这个时候就完了，外面的请求就开始变的慢，甚至开始超时。。。

学习了~！:>

大致看了下，不知道lz有没有做过性能测试，如果是大量任务的情况下，我认为会有性能问题，而且也会有多线程安全问题，如下：

1、你的workqueue，确定只要在pop的时候加锁就可以了吗？如果是多线请求往压入线程池，你确信这端不加锁是安全的？
2、在1点的基础上，如果要达到高性能，lz要好好在多线程安全队列这里性能这块研究下了，一个线程池的处理任务的速度，处理受到任务本身处理的速度影响外，它在队列处理上的性能将会是一个瓶颈；
3、lz代码在处理任务的while（true）的地方，没有做任何多线程下对cpu分配的的处理，如果是在大量任务过来的情况下，就会不间断的处理任务，你可以去做一个测试，你在机器上开到和cpu的数量相同的线程，whiletrue后不做休眠，你看看，你再启动其他线程是否能start的起来；

4、其实lz写的并不是一个线程池，只是一个任务队列而已，就是有一个队列来隔离外面请求的任务，然后开启一定数量的线程来处理这些任务而已。既然是这样，何必还在运行的时候再去new thread呢？干脆一开始就启动maxthreadcount的线程，指向这个任务队列就可以了；

5、楼主对计数器用interlocked来控制加减，但在读取这个计数器的时候却是直接读的变量，这样是会都只读取不准的，这里就会有一个漏洞，可能你启动的线程的数量会大于你定义的最大数量，当然多启动一两个线程无关精要，但假设在你判断是否已经到达最大线程数的那一刹拉有100个请求过来，那么就是会同时多出99个线程来。

上面说的几点，如有几个线程在处理的时候开不出新线程，以及会开出大大的大于定义线程数的线程。在实际使用的时候出现的概率不会太大，但既然lz把它封装成组件，那就不应该那么粗糙留下问题，因为一旦出现导致系统出问题，那是致命的。几点建议，也是一些经验之谈，贻笑大方了。

Jeffrey 怎么不见了啊，我要请问那个MSDN Magazine的地址在哪里呀~~~~

@franklin
嗯，下一步打算实现任务管理，以及线程的任务分配算法等功能。

对了，Jeffrey 同学
请问一下，你说的“ MSDN Magazine中有一个系列谈了很多这方面的问题，可以一看”，能给个连接么

因为试用了pool，我的软件用户点击了“停止”按钮后，其实系统没有马上停止，要等待线程退出，如果有取消的功能，那就好办了，直接ThreadPool.StopAll(),好爽

很好，。net的线程池的优点很多，就是没有任务管理的方法

我跟帖的主要目的是借宝地一用，问个问题，请知道怎么做的仁兄帮帮我啊，谢谢了：

在c#里面，Microsoft.Web.Services2的SoapClient,怎么设置访问service的时候使用代理？？我看了c++的可以，怎么c#的就是找不到资料啊！！help。。。。

@Jeffrey Zhao
谢老大指点,我好好研究下

其实.NET自带的线程池效率很高，经过很大调整和优化的，一般实现都比不过它。
如果不是有绝对的“违背”，只要封装一下ThreadPool就可以了，比如负载均衡，任务取消都可以实现，MSDN Magazine中有一个系列谈了很多这方面的问题，可以一看。

@Eri
多线程处理的时候啊

什么样的情况下需要自己实现线程池呢？

@ITAres
能具体说说吗？

不错，支持一下！

主要也是因为自己可控制的地方太少了
------------------
能举个例子吗，让大家了解下也好的

@Jeffrey Zhao
主要也是因为自己可控制的地方太少了

@Jeffrey Zhao
呵,头头不让用,我自己瞎搞一个了,老赵见笑了

为啥说自带的ThreadPool不适合阿？

@Todd Wei
嗯..看看,谢啦

推荐SmartThreadPool，它的feature丰富且实用。我在项目中用了很长时间，表现良好。

http://www.codeproject.com/KB/threads/smartthreadpool.aspx

嗯

感觉题目和内容不太相符。不过Keeping global data in static members of the Global class gives you strong typing以前倒没有试过。

也算学习了。

先排个版吧

学习

@Jeffrey Zhao
@fuadam
可以明确的是几乎无法完全避免使用锁机制。现在流行的做法是结合Lock-Free和锁机制来构造更加复杂的算法。

锁机制的概念其实很简单，无非就是加锁和解锁。但是在现实中，我们根本无法预测开发人员会在什么时候加锁，大多数开发人员对锁机制的理解还比较肤浅，即使是资深工程师也难免会犯错。这才是复杂的地方所在。

通用的死锁检测程序效率十分低下，而且不能保证能够检测所有的潜在危险。比方SQL SERVER就有这种程序。我们不应该把所有信任都交给它。死锁也很难在设计时预见，因为它纯粹是一种技术细节的实现。比如Java里面有个ConcurrentHashMap，撇去lock-free技术，里面有32个锁，我们如何在设计时预测，只能在实现时倍加小心。

再举个例子，Windows的事件机制(注意这里的事件不是.NET下的event，而是内核并发基元event)就被滥用了。有研究表明几乎所有的使用事件的程序都不同程度的存在隐患。而Boost库则干脆不提供event基元。

可以写通用的死锁监测程序，来避免死锁，而且在进行设计时应该能遇见死锁情况。Lock-Free只能处理简单的数据结构，如果是B-Tree或Hash这种复杂的我认为不可能不使用锁机制。

而且我觉得这个图貌似也有错误

这里是MethodTablePointer（方法表指针）还是类型对象指针？
根据楼主所说通过GetType获取MethodTablePointer ，我觉得称为 类型对象指针更合理些，CLR via C#那本书也是讲类型对象指针，因为这个类型对象里面不仅仅保存有该类型的所有方法还保存着静态字段等内容