I. 背景

在Github上也写了不少的项目了，然后经常遇到的一个问题就是，很多自己写的项目，希望在另外一个项目中使用时，只能把这个项目下载下来，相当之不方便

本文将主要说明QuickAlarm该如何使用，以及使用时需要注意事项

前面将报警规则的制定加载解析，以及报警执行器的定义加载和扩展进行了讲解，基本上核心的内容已经完结，接下来剩下内容就比较简单了

• 报警频率的统计
• 报警线程池
• 对外封装统一可用的解耦

前面两篇分别说了报警执行器和报警规则的定义及用户扩展加载，接下来就是比较核心的一块了，如何将报警规则和报警执行器关联起来，即当发生报警时，应该call哪一个报警执行器

前面一篇是报警执行器的定义与加载已经完成，但与之对应的报警规则有是如何定义和加载的呢？

此外，既然命名为规则，那么就需要有对应的解析器，以根据报警规则和报警类型等相关输入条件，来选择对应的报警执行器，因此本文主要包括的内容就比较清晰了

• 报警规则的定义
• 报警规则的加载
• 报警规则的解析以及报警执行器选择

根据前面一篇总纲的博文，将整体结构划分为了四大块，本文则主要目标集中在第一块，报警执行器（AlarmExecute）的设计与加载上了

主要的关注点无外乎 定义-》加载-》实现逻辑三块了：

• AlarmExecute 的接口定义
• 如何加载用户自定义的AlarmExecute
• AlarmExecute的内部实现

背景

日常的系统中，报警是不可缺少的一环，目前报警方式很多，最常见的有直接打日志，微信报警，短信报警，邮件报警等；而涉及到报警，一般不可避免的需要提前设置一些基本信息，如报警方式，报警频率，报警用户，开关等；

另外一个常见的问题是一般采用的是单一的报警方式，比如不管什么类型的报警全部都用短信方式触达，然后就会发现手机时常处于被淹没的状态了，久而久之对报警短信就不会敏感了

Java可以如何实现文件变动的监听

应用中使用logback作为日志输出组件的话，大部分会去配置 logback.xml 这个文件，而且生产环境下，直接去修改logback.xml文件中的日志级别，不用重启应用就可以生效

那么，这个功能是怎么实现的呢？

Java中变量的初始化顺序

在写一个通用的报警模块时，遇到一个有意思的问题，在调用静态方法时，发现静态方法内部对静态变量引用时，居然抛出了npe，仿佛是因为这个静态变量的初始化在静态方法被调用时，还没有触发，从而导致这个问题，因此今天专门来学习下静态成员的初始化顺序，以及上面这个问题导致的原因

统一异常拦截处理方式

项目中不可避免会出现一些异常情况，而一个web项目，若不拦截异常，糟糕的情况下可能直接将堆栈抛给前端，从而导致各种鬼畜的问题