纸上得来终觉浅，绝知此事要躬行——Spring boot任务调度

前言：之前今日开讲项目的时候，用到了Quartz进行任务调度。后来做一个电商项目的时候，还用到了Quartz任务调度。 觉得挺简单的，a peace of cake.  忽略了总结，当时闭着眼睛都能捉麻雀，现在睁着眼睛一片黑！

一、我最开始的想法

前提条件：对Spring boot不熟悉，对于框架代码结构也不熟悉（最近都用NetBeans，有些jar包，用到了就可以马上自动添加依赖啊，现在不行了）

我的想法是：先看看Spring boot有什么，又着重看了我需要用到的任务调度、邮件发送的部分。然后再去实施写代码，事实上，官网写得确实很明白，最开始的任务调度也很顺利

但是，问题就出在了异常报警。  我的思路是用AOP监控每一个任务的执行情况，一旦有异常发生，就发送报警邮件。但是，在织入具体注解的时候，AOP总是切不进去（欺负生人）后来就直接用了正则表达式，但是。。。。。。执手相看泪眼，竟无语凝噎！

问题：

之前一直的习惯可能是做这种非具体业务类实现的时候，第一个工程总是做测试和废弃的，所以在代码规范上就忽略了。 这样做不对，画个大大的×！

效率低下的原因是：1，没有分清楚轻重缓急；2，我不知道目前都有哪些API（为啥我找到的发送邮件API是那样的涅）

二、实践过程

1，根据文档说，Spring boot有两种任务调度的方式，第一种直接使用注解@Scheduled，第二种是通过Quartz。   因为好奇，就折腾Quartz（忽略了Spring做集成后，操作变得简单了），浪费了不少的时间。

2，当发生异常的时候发送邮件提醒就可以了，然而，我刚开始在尝试将异常任务的详细信息保存到数据库和日志（可是我明明可以把这些东西发邮件哒，无语了）

3，同事帮忙弄好了工程，然后弄了两个TODO方法，我再把代码写完了

4，分布式锁的问题，SetNX。  PS：看这个命令的时候，把redis所有的命令溜了一圈

待续。。。   等把这块儿内容做完了，再补全，先把这个事儿记录下来，思维方式严重有bug，到时候得好好规整规整！

2017.11.20续

最主要想说的，其实是在分布式锁这块内容的思维方式上，我最开始的逻辑：

1，先去redis里面取，取不到的话，就相当于没有执行任务调度，加锁—执行，取到值（被加锁），不执行当前的任务调度

2，执行错误，发送邮件

后来经过同事提醒，发现有个大bug：  当我取到值的时候，还有可能是上次的任务调度没执行结束； 还有可能是我的redis失效时间没弄对；还有可能，是我忘了执行结束后，释放锁。   很不小心的，我全中啦，无语凝噎！

经过同事的指点，然后我自己就开始不明白我为什么要先去处理redis里面取值等逻辑，然后加锁，因为这样势必会让多个线程同时进入执行一段相同代码，而这是不必要的。 所以我后来就改掉了，程序一开始就通过setNX去拿锁，拿到锁的，接着执行后续的代码！

三、思考和总结

1，为什么我会绕这么大个圈去解决问题？

2，为什么别人想的比我周全？