事件与轮询的本质和区别？

lindping 2011-12-09 11:52:44
举例

1 定义一个时钟，每隔N秒钟调用方法A一次，
2 注册一个按钮点击事件，每次点击调用方法A一次，用户每隔N秒点击该按钮1次。

这两种情形下，哪种性能更好，有本质区别吗
...全文
813 14 打赏 收藏 转发到动态 举报
写回复
用AI写文章
14 条回复
切换为时间正序
请发表友善的回复…
发表回复
Icedmilk 2011-12-12
  • 打赏
  • 举报
 回复
问题是出在谁来进行这个轮询
所谓“定时触发”的概念确实最终都要归结为你说的轮询

你让用户去轮询显然是不靠谱的。不过这是你举得一个例子

也许你想表达的是：
有两个系统A和B，A系统希望B系统来定时执行某个操作，你说的两种方法是：
1、A系统跟B系统注册一个事件，B系统通过内部的时钟来定时执行这个事件
2、A系统没隔多久去调用B系统一次

其实A系统这个每隔多久不也是要通过定时器来实现？
也没什么性能区别，
区别在于谁来进行你所说的轮询


另外，Windows的消息队列是死循环倒是真的，但那不能称为轮询吧，因为如果消息队列没有消息的话，GetMessage函数会卡在那等待消息过来
另外，现在的CPU内部都有定时器吧，这个定时器不会占用CPU的计算周期，所以轮询也不会影响性能。
另外，其实你不必纠结这个问题，而且你这个问题问的并不好，事件可能是通过轮询实现的，但是比如按钮的Click事件真的与轮询没半点联系，而计时器的事件虽然按你的说法，来说，是通过非常非常底层的轮询实现，但是我们的代码里，包括你使用的CLR，甚至操作系统都没有轮询代码，他只是调用了定时器硬件而已。

[Quote=引用 13 楼 lindping 的回复:]

我的 本质 断言 很离谱吗？
难道楼上的认为 计算机真得能做到 由事件触发？

即使是硬件的中断，本质不也是轮询？

当有设备事件产生以后,设置CPU的中断引脚触发中断,而CPU在每个时钟周期都查询是否有中断发生,在有中断时就转到中断处理程序去执行.这是典型的轮询

c#的按钮事件，本质不也是windows的消息的封装吗？windows的消息处理机制，不也是循环检测消息队列，
……
[/Quote]
lindping 2011-12-12
  • 打赏
  • 举报
 回复
我的 本质 断言 很离谱吗？
难道楼上的认为 计算机真得能做到 由事件触发？

即使是硬件的中断，本质不也是轮询？

当有设备事件产生以后,设置CPU的中断引脚触发中断,而CPU在每个时钟周期都查询是否有中断发生,在有中断时就转到中断处理程序去执行.这是典型的轮询

c#的按钮事件，本质不也是windows的消息的封装吗？windows的消息处理机制，不也是循环检测消息队列，
这本质不是一种轮询又是什么？
以专业开发人员为伍 2011-12-11
  • 打赏
  • 举报
 回复
我其实很怕有些实习生，特别是那些大学老师推荐来的所谓高材生，因为这些人往往其主要的“花哨”特征之一就是滥用Timer定时器，而且连个招呼都不打，往往偷偷使用好几个定时器之后把你的程序的性能搞得一塌糊涂根本没法用的时候，你才能去通读程序去找出这种滥用的问题。实际上一个比较听话的开发人员会尊重软件设计流程，不会滥用定时器的。

按钮事件就是按钮被按下时触发的，为什么会被认为是“定时轮询”呢？我也搞不懂怎么会有这种概念出现。我只能提前告诉你：千万不要犯这种概念错误。
以专业开发人员为伍 2011-12-11
  • 打赏
  • 举报
 回复
[Quote=引用 8 楼 lindping 的回复:]
注册一个事件，我相信本质也是一种轮询，系统不停的监控事件发生的条件，一旦满足，就触发事件，
这种方式与定义时钟去轮询的区别在哪里？
[/Quote]

你这个“本质”断言太离谱了。
以专业开发人员为伍 2011-12-11
  • 打赏
  • 举报
 回复
真想知道“本质”？

人家开发“按钮”控件时，根本不知道谁来调用它，因此才有事件设计。而你的所谓描述完全是本末倒置的，你把自己的所谓调用按钮的操作纠缠在按钮这个东西的设计需求中，这就是混乱的“本质”原因。
覃祖甘 2011-12-10
  • 打赏
  • 举报
 回复
我感觉性能方面事件比较好吧？
但是就这样的需求,做同样的工作,没必要一个人每过N秒点一次，让系统自动做行了.
阿非 2011-12-10
  • 打赏
  • 举报
 回复
用户每隔N秒点击该按钮1次。
--------------------
这个用户是不能接受的，除非每次都有“新意”

订阅模式 要比 轮询模式 相对好些 是相对服务方
使我做你和平之子 2011-12-10
  • 打赏
  • 举报
 回复
不理解你说的“用户每隔N秒点击该按钮1次”是手工进行的，还是自动进行的。如果是自动进行的，那和第一种方法没什么区别。

如果是手工进行的，那么事件的方法占用cpu少些，自然要好些。
其实这和硬件里面轮询和中断的区别差不多
绿领巾童鞋 2011-12-10
  • 打赏
  • 举报
 回复
本质啊...消息是什么啊...
lindping 2011-12-10
  • 打赏
  • 举报
 回复
每隔n秒点击一次按钮，这种场景在实际应用确实很少发生，但其实这是我假设的一种场景，
其实我的意思是a系统使用事件触发 执行某个方法M，例如点击按钮时执行M，
b系统使用时钟 定时执行同样的方法M，那么系统a与系统b在方法M均未执行的状态下，哪个更消耗系统资源？

注册一个事件，我相信本质也是一种轮询，系统不停的监控事件发生的条件，一旦满足，就触发事件，
这种方式与定义时钟去轮询的区别在哪里？
Kelvin峰 2011-12-10
  • 打赏
  • 举报
 回复
如果说性能更好，那肯定是事件的性能更好。
如果说实时性更高，肯定是轮询的实时性更高，但比较耗费系统资源。
比如微博~~不断的轮询查询数据库，对服务器的负荷要求比较高
nimenshishabi 2011-12-10
  • 打赏
  • 举报
 回复
[Quote=引用 3 楼 love_gg 的回复:]

让用户自己每隔N秒点击一次这样的需求有点怪异，一般不会有这样的需求。
用timer吧，可以设置执行时间，它的机制是新启动了一个线程来执行你的函数。注意一点，如果对时间的精度要求很高，就不要用timer，有细微的偏差。
[/Quote]
用时钟比较好把，至少时间比较精确。
stonespace 2011-12-10
  • 打赏
  • 举报
 回复
呵呵用户手工点击要占用用户的工时，是要按照时间结算工资的，而时钟自动调用不需要占用人工，可以节省用户的成本，

用户一般会喜欢时钟，不过也有例外，
LOVE_GG 2011-12-10
  • 打赏
  • 举报
 回复
让用户自己每隔N秒点击一次这样的需求有点怪异，一般不会有这样的需求。
用timer吧，可以设置执行时间，它的机制是新启动了一个线程来执行你的函数。注意一点，如果对时间的精度要求很高，就不要用timer，有细微的偏差。
尚硅谷_延迟队列与轮询.docx
本教程特点： 1.更适合零基础学员： ·自Java语言起源始，循序渐进，知识点剖析细致且每章配备大量随堂练习，让你步步为营，学得透彻、练得明白 ·拒绝晦涩难懂的呆板教学，宋老师语言生动幽默，举例形象生动深入浅出，迅速让你把握问题本质，四两拨千斤 2.课程内容推陈出新： ·基于JDK 11，将Java8、Java9、Java10、Java11新特性一网打尽 ·课程中，Eclipse和IDEA这两种企业一线开发环境都使用到了 3.技术讲解更深入、更全面： ·课程共30天，715个知识视频小节，涉及主流Java使用的方方面面，全而不冗余 ·全程内容涵盖数据结构、设计模式、JVM内存结构等深度技术
java websocket
传统的HTTP协议是无状态的，每次请求（request）都要由客户端（如 浏览器）主动发起，服务端进行处理后返回response结果，而服务端很难主动向客户端发送数据；这种客户端是主动方，服务端是被动方的传统Web模式 对于信息变化不频繁的Web应用来说造成的麻烦较小，而对于涉及实时信息的Web应用却带来了很大的不便，如带有即时通信、实时数据、订阅推送等功能的应 用。在WebSocket规范提出之前，开发人员若要实现这些实时性较强的功能，经常会使用折衷的解决方法：轮询（polling）和Comet技术。其实后者本质上也是一种轮询，只不过有所改进。 轮询是最原始的实现实时Web应用的解决方案。轮询技术要求客户端以设定的时间间隔周期性地向服务端发送请求，频繁地查询是否有新的数据改动。明显地，这种方法会导致过多不必要的请求，浪费流量和服务器资源。 Comet技术又可以分为长轮询和流技术。长轮询改进了上述的轮询技术，减小了无用的请求。它会为某些数据设定过期时间，当数据过期后才会向服务端发送请求；这种机制适合数据的改动不是特别频繁的情况。流技术通常是指客户端使用一个隐藏的窗口与服务端建立一个HTTP长连接，服务端会不断更新连接状态以保持HTTP长连接存活；这样的话，服务端就可以通过这条长连接主动将数据发送给客户端；流技术在大并发环境下，可能会考验到服务端的性能。 这两种技术都是基于请求-应答模式，都不算是真正意义上的实时技术；它们的每一次请求、应答，都浪费了一定流量在相同的头部信息上，并且开发复杂度也较大。 伴随着HTML5推出的WebSocket，真正实现了Web的实时通信，使B/S模式具备了C/S模式的实时通信能力。WebSocket的工作流程是这 样的：浏览器通过JavaScript向服务端发出建立WebSocket连接的请求，在WebSocket连接建立成功后，客户端和服务端就可以通过 TCP连接传输数据。因为WebSocket连接本质上是TCP连接，不需要每次传输都带上重复的头部数据，所以它的数据传输量比轮询和Comet技术小 了很多。本文不详细地介绍WebSocket规范，主要介绍下WebSocket在Java Web中的实现。 环境：jdk1.8.0_111，apache-tomcat-8.0.51
DockerToolbox-1.12.6.exe
RESCALE rescale()方法亦以轮询【round-robin】的方式分发事件，但仅将任务分配给后继任务【successor task】的子集上。 从本质上讲，重新缩放分区策略【rescale partitioning strategy】提供了一种在数据流图包含扇出模式时执行轻量级负载再平衡的方法。 rebalance()和rescale()之间的根本区别在于形成的任务连接的方式。 虽然rebalance()将在所有发送端任务与所有接收端任务之间创建通信通道【communication channels 】，但rescale()将仅创建从每个任务到下游操作符的某些任务的通信通道【communication channels 】。
websocket:WebSocket protocol 是HTML5一种新的协议。它实现了浏览器与服务器全双工通信(full-duplex)
HTML5 WebSocket 设计出来的目的就是要取代轮询和 Comet 技术，使客户端浏览器具备像 C/S 架构下桌面系统的实时通讯能力。 浏览器通过 JavaScript 向服务器发出建立 WebSocket 连接的请求，连接建立以后，客户端和服务器端就可以通过 TCP 连接直接交换数据。因为 WebSocket 连接本质上就是一个 TCP 连接，所以在数据传输的稳定性和数据传输量的大小方面，和轮询以及 Comet 技术比较，具有很大的性能优势。 下面是一段简单的 JavaScript 代码展示了怎样建立 WebSocket 连接和获取数据： var wsServer = 'ws://localhost:8888/Demo'; var websocket = new WebSocket(wsServer); websocket.onopen = function (ev
websocket-protocol:websocket协议
近年来，随着HTML5的诞生，WebSocket协议被提出，它实现了浏览器与服务器的全双工通信，扩展了浏览器与服务端的通信功能，使服务端也能主动向客户端发送数据。传统的HTTP协议是无状态的，每次请求（request）都要由客户端（如浏览器）主动发起，服务端进行处理后返回response结果，而服务端很难主动向客户端发送数据；这种客户端是主动方，服务端是被动方的传统Web模式对于信息变化不频繁的Web应用来说造成的麻烦较小，而对于涉及实时信息的Web应用却带来了很大的不便，如带有即时通信、实时数据、订阅推送等功能的应用。在WebSocket规范提出之前，开发人员若要实现这些实时性较强的功能，经常会使用折衷的解决方法：轮询（polling）和Comet技术。其实后者本质上也是一种轮询，只不过有所改进。 轮询是最原始的实现实时Web应用的解决方案。轮询技术要求客户端以设定的时间间隔周期性地向服
C#

110,534

社区成员

642,576

社区内容

发帖
与我相关
我的任务
社区描述
.NET技术 C#
社区管理员
  • C#
  • Web++
  • by_封爱
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告

让您成为最强悍的C#开发者

试试用AI创作助手写篇文章吧

+ 用AI写文章