在我的系统中，用户可以创建包含时间和条件的计划。在30分钟的计划时间之前，如果条件不满足，系统将发出警报以通知用户。
我的系统是弹簧启动应用程序，使用弹簧计划任务触发警报。问题是当用户将来创建大量日程安排时，如果我为每个日程安排数据创建一个计划任务，就会出现内存问题。
我目前的解决方案是在每天的时间创建一个计划，以便在接下来的24小时内扫描所有数据，并为他们创建计划任务以触发警报。这将减少创建的计划任务，但如果用户在扫描后的24小时内创建新的计划数据，则该数据不会触发任何警报。
那我该怎么办？
答案 0 :(得分：0)
您是否有理由在JVM内存中安排所有这些？如果JVM崩溃（或只是重新启动），则定时器将丢失，就像用户从未安排任何警报一样。如您所述，为每个请求创建一个计时器可能不是一个可扩展的解决方案。
在不知道系统的具体细节的情况下，最常见的方法是每次用户请求安排事件时持久（即在DB，平面文件等中）数据。这样，在发生崩溃或重启时，您不会丢失事件。同样，如果需要，此方法可以扩展到多个服务器。然后，无论您支持多少粒度（即分钟，小时，天等），都会有一个进程或线程（只有单个监视器线程）找到已过期的所有事件，因为你上次跑了。最后，一旦该线程识别出需要“警报”的事件，该一个线程就可以控制发送这些事件以进行活动处理。此线程可以单独处理每个事件，也可以将它们提交到活动工作队列以进行并行化。
更具体地说，如果您有任何分钟的闹钟，那么您应该安排一个监听线程每隔分钟运行一次。该线程应该找到所有需要报警的事件，然后实际发送该报警。
请记住，您应该多长时间安排一次监控线程，这取决于您对警报所需的分辨率以及您对延迟警报的容忍度。如果延迟警报完全不可接受，那么您的监视器必须至少运行，并且最精细的粒度用于安排警报事件。当然，这是假设将来始终安排警报 - 否则，您可能希望将监控检查的频率加倍。要了解原因，请考虑以下示例：
minute 0: Run monitor
minute 0: User schedules alarm for minute 0
minute 1: Run monitor
如果我们每分钟运行一次监视器但允许用户在当前分钟内安排警报，那么我们很可能会错过该事件（如上例所示）。如果有必要，我可以更深入地讨论这个问题，但这主要是为了完整性，因为我从你的描述中没有迹象表明这实际上会带来任何问题。
祝你好运。