1. Spring Batch2的新的特性
Spring Batch2.0有六个主要的主题：
Ø Java 5
Ø 非顺序的步骤
Ø 基于块的处理
Ø 元数据扩展
Ø 伸缩性
Ø 可配置
1.1. Java 5
Spring Batch的1.x版本基于Java 1.4，这样限制了框架使用1.5的一些新的特性，比如：泛型和参数化类型。整个框架都做了调整来适应新的特性。所心，1.4已经不再支持了。开发者使用的大多数接口已经泛型化。例如，ItemReader接口在1.x中，如下面所示：
就像你所看到的那样，read方法返回了一个Object。2.0中，如下所示：
可以看到，2.0已经支持泛型，参见read函数的返回值，你也可以看到，mark和reset已经被移除，这是因为处理流程上的改变，这会在后面提到，很多其它的函数也像这样进行了更改。
1.2. 基于块的处理
以前，默认的处理规则就是基于项的处理。
在基于项的处理中，ItemReader返回了一个对象，然后交给了ItemWriter，当数量达到了commit interval规定的值的时候，进行阶段性的提交。例如，如果commit interval设置成５，ItemReader和ItemWriter每个都被调用５次，下面就是一个代码的结构：
ItemReader和ItemWriter都被完全绑定起来：
由于处理的范围是一个item，支持回滚的场景就需要额外的方法，这就是mark，reset，flush和clear。如果成功读写了两条数据，而第三条在写的时候出现了错误，事务就需要回滚，在这种情况下，writer的clear方法就会被执行，表示它应当清空自己的buffer，然后ItemReader的reset方法就会被调用，表示它应当回到上一个mark方法被调用的点。
在2.0里面，策略被改成了基于块的结构：
使用上面相同的例子，如果commit interval是５的话，read就会被执行５次，但write只会被执行一次。这些数据项会被放进一个list里面，然后被同时写出，下面是一个能够简单说明问题的例子：
这个修改不仅让处理和伸缩更加简单，而且也让ItemReader和ItemWriter更加的清晰。
就像你所看到的，接口不再有mark，reset，flush和clear方法，这让开发者感觉readers和writers的创建更加的直接。对于ItemReader接口，只会向前走。如果需要回滚的话，框架会自动为开发者缓存数据项。ItemWriter是如此的简单，由于它一次拿到了个块的数据，不再是一次一个，在把控制权交还给step之前，可以输出任何资源。
1.2.1. 项处理器
以前，Steps仅仅只有两个依赖，ItemReader和ItemWriter。
上面的基础配置确实是十分的健壮，但是，有很多的情形，item需要在交给writer之前进行转换。在1.x中，这需要用组合模式进行实现。
这的确起作用，但是这需要在reader、writer和step之间增加新的一层。更重要的是，ItemWriter需要作为一个ItemStream在Step中进行单独地注册。因为这个原因，ItemTransfomer改名为ItemProcessor，而且移到了和ItemReader及ItemWriter的同一层。
1.3. 配置扩展
2.0以前，唯一的配置Spring Batch的方法就是像SpringBean一样的配置方式。但是在2.0，有了新的名字空间。例如，在1.1里面，像下面这样配置一个任务。
在2.0里面，等效的配置如下：
1.4. 元数据访问提升
JobRepository接口，实现在基本的使用Job元数据进行CRUD操作，而且，这在查询的时候也会很有帮助。因为这个原因，JobExplorer和JobOperator才被定义出来。
1.5. 非序列的步执行
在step的配置方面，2.0也有了很大的提升，而不在仅仅是一条线的往下走。
现在是可以选择的：
使用新的名字空间，可选择的step变得十分的容易。
1.6. 扩展性
Spring Batch1.x期望作为一个单独的vm，也许是多线程模型，但是很多的多进程并发的特性被编译进去。基于Spring Batch服务特性的目标，很多项目实现了一个可伸缩的解决方案，来保证进程只会在一个有顺序的情况下发生。在2.0里面，这些显得现的更加的透明，有两种可伸缩的方案，remote chunking和partitioning。
1.7. Remote Chunking
Remote Chunking是一种把一个step的工作进行分解的技术，而且不需要任何额外的对数据结构的了解。一个输入源可以被动态的拆分，一个进程进行读，任务的处理被分发到远端的工作线程。远端实现了一个监听模式，响应一个请求，处理数据，发送一个异步的回复，请求和回复的传送必须被分发者和一个单独的消费者保持起来。这种特性使得任何JMS的实现都变得可读。由于Spring Batch是在Spring Integration的顶层构建的Remote Chunking，因此对于消息中间件来说，它是不可知的。
1.8. Partitioning
对于输入的数据的结构有一些了解的话，Partitioning（分发）也是一个可以尝试的途经。像一系列的主键，或者一个要处理的文件的名字。这个模型的优点就是，每个处理程序，就像一个单独的Job，它们不需要实现任何特殊的新的模式，这让它们很容易配置和测试。原则上来讲，Partitioning比Remote Chunking有更好的伸缩性，因为这没有在一个地方进行文件读操作的瓶颈。
在Spring Batch2里面，Partitioning需要两个接口的支持：PartitionHandler和StepExecutionSplitter，PartitionHandler知道执行的结构，它必须发送请求到远端的steps，收集执行结果。PartitionHandler是一个SPI，Spring Batch提供了一个可在本地运行的实现，通过一个TaskExecutor。这十分有用，如果这是一个IO十分频繁的操作的话，由于在这些情况下远程执行只增加了复杂度，却没有性能上的提升。其它的实现可能是和运行时的结构进行绑定。
