c# – 在ASP.NET中使用线程是否有任何非明显的危险？

发布时间：2020-12-15 07:40:14 所属栏目：百科来源：网络整理

导读：这是 this programmers question的兄弟问题. 简而言之,我们正在考虑将一些支持用户请求的工作推送到后台“正确”.如果我们走的是服务路线,这个相关的问题给了我很多想法,但是并没有真正提供任何令人信服的论据,说明为什么我们应该这样做. 我会承认,对我来说,

这是 this programmers question的兄弟问题.

简而言之,我们正在考虑将一些支持用户请求的工作推送到后台“正确”.如果我们走的是服务路线,这个相关的问题给了我很多想法,但是并没有真正提供任何令人信服的论据,说明为什么我们应该这样做.

我会承认,对我来说,做道德等同的能力

WorkQueue.Push(delegate(object context) { ... });

真的很引人注目,所以如果它有点困难(而不是天生就不可行),我倾向于采用后台线程方法.

所以,我知道的后台线程问题(在AppPool的上下文中)：

>由于AppPool被回收,它们可能随时死亡

>解决方案：跟踪任务执行的时间,因此可以重新运行*如果需要新线程

> ThreadPool用于响应传入的HTTP查询,因此使用它可能会使IIS饿死

>解决方案：构建我们自己的线程池,同时限制线程数.

我的问题是,如果有的话,我错过了什么？在ASP.NET中使用后台线程会出现什么问题？

*问题中的任务已经安全重新运行,所以这不是问题.
?假设我们没有做任何真正愚蠢的事情,比如在后台线程中抛出异常.

解决方法

我将远离启动用于StackOverflow的IIS AppDomain中的线程.我没有任何确凿的证据来支持我要说的话,但是在IIS上工作了10年,我知道当它是城里唯一的游戏时效果最好.

还有一个替代方案,我知道这将是程序员线程上的take off on my answer.但据我所知,你已经有了一个解决方案,通过捎带工作用户请求.为什么不使用该代码,而只在调用特殊内部API时启动它.然后使用Task Scheduler调用CURL命令,该命令每隔30秒左右调用该API以启动任务.这样您就可以让IIS处理线程,并且您的代码正在处理它已经轻松完成的操作.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!