事件源，事件对象，监听器
1.首先，事件源一般不是由我们可以定义的，tomcat自己有定义，mq自己有定义，
事件源是来注册监听器，并且把事件对象传递给监听器的
2.事件对象，就是我们要传递给监听器的东西，tomcat有自己的事件对象定义规范，mq
也有，例如tomcat有 servlet的生成销毁这个事件对象，mq消息的生成也是事件对象，
事件对象一旦产生，就会触发事件源去通知监听器（带着事件对象），去执行相应的方法
事件对象一般也不是我们自己定义的，我们一般只定义监听器对事件对象的处理
3.一定要区分事件对象与监听器的区别，说白了我们说的监听器就是事件发生后对事件的处理，
至于事件的发生，事件源将事件对象传递给监听器，这个都不是我们要考虑的，这个都是应用程序规定好的
我们能做的就是定义监听器处理事件对象的方法
4.关于事件对象的发生，和事件源将事件对象传递给监听器执行，这个一般是异步的
1.怎么理解：
1.例如tomcat的请求过来这个例子，首先tomcat可能会有一个专门处理请求的线程，也可能就是在main中处理
一旦请求过来，就会开启一个新的线程处理这个请求，这个过程不是说tomcat在
监听线程，这个不是监听器，至于这个一直可以处理请求的设计是怎么处理的暂时不考虑
当请求过来，tomcat用request封装了请求的信息，这个事件完成后，相当于事件对象产生
这时，事件源会通知监听器去拿到事件对象（这里就是request）,这里可以理解成这里开启了一个线程去通知监听器
下一步就过filter,在就到了servlet了
2.这样不管监听器执行多久，都不会妨碍我接受下一个请求处理下一个请求，从这个角度来说是异步的
3.当然这个有个疑问：
listener和filter和servlet的执行顺序问题：
上面说了请求过来封装信息，后面开启线程去通知listener
然后走filter,filter走完，再开启一个servlet线程
这就是说顺序是listener(这一步是开启异步的，但是tomcat开启异步处理listener这也是首先处理listener)
然后走filter这步直到完成都是同步的，然后在走servlet
4.再举一个例子：mq
mq产生消息了，消费者就会消费消息（这个理解成tomcat请求过来，就会封装请求信息），
至于mq怎么会一直可以等待消息来然后消费掉，这个看起来像是监听其实不是
消费完消息，异步调用事件源去通知监听器去执行
这样异步的好处是不管监听器执行时间有多长，我的mq都会消费其他消息
5.说白了，事件的发生这个应用程序会一直有一个线程来处理它，怎么实现的步直到
事件发生完，事件源就会异步调用监听器处理事件对象，而线程继续处理事件对象的产生
6.事件对象：可以理解成事件发生后，产生的对象，这个是应用程序规定的
例如：tomcat处理请求的线程，事件的发生就是请求过来，产生的事件对象就是封装请求信息的request
mq消费消息这个是事件的发生，消费的消息body就是事件对象