Gecco学习日记02：Debug分析
Gecco的目标是提供一个完善的主题爬虫框架，简化下载和内容抽取的开发，利用管道过滤器模式，提供灵活的内容清洗和持久化处理模式，让开发人员把更多的精力投入到与业务主题相关的内容处理上。
Debug分析
由于上节我们在启动quickstart之后，打印出了错误信息mismatch。通过log4j打印的错误，我们发现问题出现在Spider这个类中。
但是为了更好的明白Gecco的运作方式和Debug错误，我们先对GeccoEngine这个类进行了分析。
Gecco引擎初始化梳理
GeccoEngine是一个线程类，其中包含一些关键类有：
状态性的——
请求队列：Scheduler，装着请求对象的队列
请求类：Request，代表一个应该进行的请求，存放在请求队列中，多个爬虫对象并发地从队列中取得请求对象，根据之发起HTTP请求
响应类：Response，将爬虫对象发起HTTP请求后获得的结果，封装成响应对象，由Render转换成实体对象
行为性的——
引擎类：Engine，总的配置和入口
爬虫类：Spider，一个引擎可以有多个爬虫对象并发工作，每个爬虫对象有一个单独的线程，爬虫的线程主循环中，从请求队列中获得请求对象，交给下载器
下载器：Downloader，用于根据一个请求对象，发起一次HTTP请求，将HTTP响应封装成响应对象
转换器：Render，用于将响应对象转换成用户定义的实体类的对象，实现方式是通过反射读取实体类的字段上的注解并处理
在run()中我们熟悉了，GeccoEngine的具体流程：
- 首先GeccoEngine进行一系列初始化（scheduler、spiderBeanFactory、startRequests、spiders）
- scheduler将需要下载的请求都放在这里管理，可以认为这里是一个队列，保存了所有待抓取的请求。
- 每个爬虫(Spider)可以认为是一个单独线程，在每个爬虫对象线程的主循环中，爬虫会从Scheduler中获取需要待抓取的请求对象，由下载器进行下载。爬虫的任务就是下载网页并渲染相应的JavaBean。
- 下载器(Downloader)，使用请求对象(startRequests)，发起HTTP请求，把HTTP响应封装成响应对象
- 转换器，使用响应对象，及实体类上的注解信息，将响应对象渲染成有业务意义的实体对象
- 在爬取信息过程中，GeccoEngine会监控爬虫的基本信息，并导出jmx信息
Spider类
通过查看Spider的源码我们发现，原来问题在这:
在这里我们发现，之所以出现错误信息，只有一种可能：
- currSpiderBeanClass为空，且response.getStatus（）不为302 或 301。
所以，为什么currSpiderBeanClass会为空呢？我们继续找，发现其实是因为
engine.getSpiderBeanFactory().matchSpider(request) 为null
这是什么意思呢？猜测因该是engine的SpiderBeanFactory这个工厂类中创建Spider出现了问题
刨根问底，继续往SpiderBeanFactory找。查看matchSpider方法，发现了问题所在。
SpiderBeans这个concurrentHashMap是空的。。。那么是谁应该创造SpiderBeans呢？
我们找到了addSpiderBean（）这个方法
按道理，这里SpiderBeans应该要存放一些东西，虽然现在不太清楚放些什么。。。
但是既然如此，我们就利用log4j以及获得调用栈来看看是哪个调用addSpiderBean(好像在挖祖坟的感觉。。。)
通过打印的log，我们可以看到SpiderBeanFactory先进行初始化，然后loadSpiderBean，那么问题就肯定在这两者中。
最终，我们分析这段SpiderBeanFactory的构造函数，发现这个工厂类原来在利用反射来进行一系列初始化，同时也知道了spiderBean的本质是一个ConcurrentHashMap，而反射读取的路径是com.geccocrawler.gecco包下的。
这里，我们明白了SpiderBeans是在SpiderBeanFactory初始化的时候就被new出来的，而至于为什么
本篇作为过渡，接下几篇对该包下所有包逐一分析。(🕊🕊🕊🕊🕊)
