(Win/C#/.Net) Applet 需要每小时轮询 - 关于最佳方法的建议？
Applet 需要轮询目录是否存在，例如每 1-4 小时轮询一次，如果未找到，则发送几封电子邮件/NET SEND。具体间隔时间还不确定，但肯定不会短于1小时。在可预见的未来，整个“工作”将是永久性的、持续运行的。 Applet 将在 Win2k3 服务器上运行，并且基于（极轻）用户使用模式，我怀疑它会以任何明显的方式干扰主服务器功能，但当然只是希望它表现良好！最终考虑将其实现为 Win 服务，但由于各种原因，首先实现将作为控制台应用程序。
寻求在系统资源使用方面最精简的实现，特别是 CPU 和 RAM。 最关心的是计时/轮询实现与 CPU 使用情况。不会创建大量对象、GUI 等，因此 RAM 使用情况应该不是什么大问题，但我需要吗如果我将垃圾收集作为长期运行的 .exe 来实现（在几个月/几年的意义上），要特别考虑垃圾收集吗？
文件系统观察者？
系统.定时器.定时器？
线程.睡眠？
其他？
实际上，当我写这篇文章时，最简单的实现——从重用为此类任务发明的许多现有“轮子”的角度来看——将根本不进行轮询，而是简单地设计它来启动，执行操作，然后关闭，并让 Windows 计划任务基础结构处理计时方面。但无论如何我还是发布了这个想法的验证+一般信息以供将来参考。泰！
Applet needs to poll for existence of a directory, say, every 1-4 hours, and send a couple emails/NET SENDs if it is not found. Not sure on exact interval yet, but it will definitely not be shorter than 1 hour. The overall "job" will be permanent and continuously-running for the foreseeable future. Applet will be running on a Win2k3 Server, and based on (extremely light) user usage patterns, I doubt it will interfere in any noticeable way with primary server functions, but just want it to be well-behaved, of course! Considered implementing it as a Win Service eventually, but for various reasons, first implementation will be as a console app.
Seeking the implementation that will be leanest in terms of system resource use, specifically CPU and RAM. Concerned most about the timing/polling implementation vs. CPU usage. There will not be a ton of objects, GUI, etc. created, so RAM usage should not be much of an issue, but do I need to give special consideration to Garbage Collection if I do implement it as a long-running .exe (in the months/years sense)?
FileSystemWatcher?
System.Timers.Timer?
Thread.Sleep?
other?
Actually, as I write this, it occurs that the simplest implementation -- from the standpoint of reusing the many existing "wheels" already invented for this type of task -- will be to not poll at all, but simply design it to start, perform actions, and close, and let Windows Scheduled Tasks infrastructure handle the timing aspect. But I posted anyway to get validation of that idea + general info for future reference. TY!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
使用 Windows 计划服务来计划控制台应用程序的运行。使用 Directory.Exists 对目录进行简单检查，并根据需要发送电子邮件。
Use Windows Scheduling Services to schedule the running of your console app. Do a simple check for the directory using Directory.Exists and send emails as necessary.
我会将其设计为作为无头应用程序运行（记录到事件日志或您选择的接收器），并让任务计划程序完成其工作并按时调用它。
没必要把事情搞得太复杂。
I'd go with designing it to run as a headless application (logging to the event log or your sink of choice) and letting the Task Scheduler do its job and call it on the hour.
No need to overcomplicate things.
Windows 计划任务绝对是最佳选择。 Thread.Sleep(n) 绝对不是正确的选择。如果您要在应用程序中执行此操作，则可以选择 System.Timers.Timer，初始间隔为 3600000。在每个 Elapsed 事件中，您应该禁用计时器，执行以下操作无论您需要执行什么代码，然后重新启用计时器，其间隔等于下一个整点整点减去当前系统时间。否则你的计时器将与系统时间不同步（尽管这对于你的目的来说可能并不重要，在这种情况下就让它见鬼去吧）。
Windows Scheduled Task is definitely the way to go. And Thread.Sleep(n) is definitely not the way to go. A
System.Timers.Timerwould be the way to go if you were going to do this from within your application, with an initial interval of 3600000. In each Elapsed event, you should disable the Timer, do whatever code you need to do, then re-enable the Timer with an Interval equal to the next hour-on-the-hour minus the current system time. Otherwise your Timer will drift out of sync with the system time (although this might not matter for your purposes, in which case to hell with it).过去，我通过简单地创建一个控制台应用程序并让它从 Windows 计划任务中执行来处理类似的任务。这样它就可以执行其操作，然后从内存中卸载。此外，如果需要对服务器执行工作（例如系统升级），可以轻松地暂时禁用计划任务。此外，如果计划需要更改（更多/更少），计划任务界面已经考虑了多次运行。
In the past I've handled tasks like that by simply creating a console application and having it execute from a Windows Scheduled Task. That way it can perform its action and then unloaded from memory. Also, it's easy to temporarily disable the scheduled task if there's work that needs to be done to the server (like system upgrades). Also, it the schedule needs to change (more/less often), the scheduled task interface already accounts for multiple runs.
我们尝试编写与 Windows 服务类似的工具（正如您所说的未来的实现），原因如下：
请注意，我们开发了一个用于创建这些项目的框架和关联模板；这样每个项目就不必处理轮询间隔的配置等。
We've tried to write similar tools as Windows Services (as you said a future implementation may be) for several reasons:
Note that we developed a framework and associated template for creating these projects; that way each project doesn't have to handle configuration of the polling interval, etc.