环境是阿里云服务器2核4G,性能有限。
用计时器和多线程感觉都不好。计时器单线程一个任务没执行完,另一个会受阻;多线程怕线程多了占用太多内存达到内存峰值,影响其他网站正常运行。有没有好的解决方案呢?
9 个解决方案
#1
假如你的任务是1秒以此,3秒执行完,那么必须多线程,至少3个,否则执行不完。。。用线程池即可,你也说了1-3秒,那用上限是5个信号量限制将同时运行此类任务的线程数量控制为5以下,肯定是没问题的,就算运气不好执行了5秒,也没问题。。。
#2
按每一次任务用时3秒来算,每秒启动一个进程,同时存在的进程最多也只有三个,哪来太多线程?
#3
编程控制负载的方法,是信号量,任何操作系统都有,.net也有,你不妨百度下或者F1查下他的用法,很简单的。。。
#4
1 首先 我记得计时器 不会受阻,楼主可以简单测试一下 ,
2 其次么,既然你是1秒执行1次,一次长达3秒。那么为了不必要的不断创建线程,完全可以使用线程池嘛。
我觉得使用线程池最合理 ThreadPool
2 其次么,既然你是1秒执行1次,一次长达3秒。那么为了不必要的不断创建线程,完全可以使用线程池嘛。
我觉得使用线程池最合理 ThreadPool
#5
因为之前用过后台工作者处理过类似的事情,不知道为什么占用了挺大内存,效果不好。
#6
好的,就是不知道搜什么
#7
好的,我试试。
#8
quartz……
因为我有类似支付宝支付成功回调的业务,所以我现在正在写一个基于quartz的定时执行任务,失败retry的小类库
至于并发问题,因为用的还是quartz的job,完全可以依赖job的并发attribute声明控制
因为我有类似支付宝支付成功回调的业务,所以我现在正在写一个基于quartz的定时执行任务,失败retry的小类库
至于并发问题,因为用的还是quartz的job,完全可以依赖job的并发attribute声明控制
#9
但感觉你这个好像不需要quartz,完全可以用LimitedConcurrencyLevelTaskScheduler来控制并发执行的数量,可以参考下
https://blog.csdn.net/starfd/article/details/79711915
#1
假如你的任务是1秒以此,3秒执行完,那么必须多线程,至少3个,否则执行不完。。。用线程池即可,你也说了1-3秒,那用上限是5个信号量限制将同时运行此类任务的线程数量控制为5以下,肯定是没问题的,就算运气不好执行了5秒,也没问题。。。
#2
按每一次任务用时3秒来算,每秒启动一个进程,同时存在的进程最多也只有三个,哪来太多线程?
#3
编程控制负载的方法,是信号量,任何操作系统都有,.net也有,你不妨百度下或者F1查下他的用法,很简单的。。。
#4
1 首先 我记得计时器 不会受阻,楼主可以简单测试一下 ,
2 其次么,既然你是1秒执行1次,一次长达3秒。那么为了不必要的不断创建线程,完全可以使用线程池嘛。
我觉得使用线程池最合理 ThreadPool
2 其次么,既然你是1秒执行1次,一次长达3秒。那么为了不必要的不断创建线程,完全可以使用线程池嘛。
我觉得使用线程池最合理 ThreadPool
#5
因为之前用过后台工作者处理过类似的事情,不知道为什么占用了挺大内存,效果不好。
#6
好的,就是不知道搜什么
#7
好的,我试试。
#8
quartz……
因为我有类似支付宝支付成功回调的业务,所以我现在正在写一个基于quartz的定时执行任务,失败retry的小类库
至于并发问题,因为用的还是quartz的job,完全可以依赖job的并发attribute声明控制
因为我有类似支付宝支付成功回调的业务,所以我现在正在写一个基于quartz的定时执行任务,失败retry的小类库
至于并发问题,因为用的还是quartz的job,完全可以依赖job的并发attribute声明控制
#9
但感觉你这个好像不需要quartz,完全可以用LimitedConcurrencyLevelTaskScheduler来控制并发执行的数量,可以参考下
https://blog.csdn.net/starfd/article/details/79711915