2020-05-12更新：因为我们的业务并不允许使用jpa的级联操作以及mysql的外键，所以只是学习了这篇文章但是并没有试过其中的代码。今天想起来把代码测试了一遍，并修正了文中的一些说法。

这是我看过的解释的最清楚的一篇文章。本来只想放个链接，但是怕链接原文被删了，所以把原文也复制过来并重新排版。感谢作者。
原文链接：http://westerly-lzh.github.io/cn/2014/12/JPA-CascadeType-Explaining/

1. 背景

  网上关于JPA的CascadeType讲解很多，但几乎都说的很模糊。本文试图使用一个具体的例子来说明CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH, CascadeType.REMOVE, CascadeType.ALL 具体区别。
  我们使用一个订单和订单项的例子。该例子在网络上那些介绍JPA CascadeType用法的文章中广为流传。

2. 使用的代码

/**
 * 订单
 */
@Entity
@Table(name="t_order")
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;
    @Column
    private String name;
    @OneToMany(mappedBy="order",targetEntity=Item.class,fetch=FetchType.LAZY)
    private List<Item> items;
}

/**
 *订单物品
 */
@Entity
@Table(name="t_item")
public class Item {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;
    @Column
    private String name;
    @ManyToOne(fetch=FetchType.LAZY,targetEntity=Order.class)
    @JoinColumn(name="order_id")
    private Order order;
｝

/** Order Repository */
public interface OrderRepository extends JpaRepository<Order, Integer>,
    JpaSpecificationExecutor<Order> {

}

/** Item Repository */
public interface ItemRepository extends JpaRepository<Item, Integer>,
    JpaSpecificationExecutor<Item> {

}

通过jpa自动建表，这时候item表中有一个字段order_id，是order表的id，这是一个外键约束，记住这一点，很重要。

3. 新增(保存)数据(CascadeType.PERSIST)

  客户每次下完订单后，需要保存Order，但是订单里含有Item，因此，在保存Order时候，Order相关联的Item也需要保存。采用上面的模型，使用如下的测试代码：

@Test
public void addTest(){
    Order order = new Order();
    order.setName("order1");

    Item item1 = new Item();
    item1.setName("item1_order1");
    item1.setOrder(order);

    Item item2 = new Item();
    item2.setName("item2_order1");
    item2.setOrder(order);

    List<Item> items = new ArrayList<Item>();
    items.add(item1);
    items.add(item2);
    order.setItems(items);

  //代码段1
    orderRepository.save(order);
    Assert.assertEquals(1,orderRepository.count());
    Assert.assertEquals(2,itemRepository.count());

    //代码段2
    itemRepository.save(items);
    Assert.assertEquals(1,orderRepository.count());
    Assert.assertEquals(2,itemRepository.count());
}

3.1 在该场景中，我们分别测试了如下情况：

3.5 结论

  在某个类的某个级联属性上使用CascadeType.PERSIST，对该类进行保存操作时，可以级连保存该类中此属性所对应的对象；而对该类的属性对应的对象进行保存操作时，却不能保存该类；存在外键的一方时，因为外键的约束并不能单独保存。
  如果在该类和该类的属性所对应的类别中同时使用CascadeType.PERSIST，无论是从该类出发进行保存操作，还是从该类的属性对应的对象出发进行保存操作，都可以保存二者。

4. 删除数据(CascadeType.REMOVE)

  现在有这样的场景，客户需要删除一个订单,那么订单中的订单项也需要一并删除，为了可以实现级连删除的效果，我们使用以下测试代码：

@Test
public void testDelete(){
    //代码段3
    orderRepository.delete(order);
    Assert.assertEquals(0, orderRepository.count());
    Assert.assertEquals(0, orderRepository.count());

    //代码段4
    itemRepository.delete(items);
    Assert.assertEquals(0, orderRepository.count());
    Assert.assertEquals(0, itemRepository.count());
}

4.1 在该场景中，我们分别测试如下情况:

4.2 结论

  在一般的业务场景中，需求基本是在删除order时同时级连删除items，但反过来，在删除items的时候同时也要求删除order却不是很适合；即使删除了所有和order相关的items，可能也需要保持住那个没有items的order。
  这里的建议是，最好不要在Item类使用CascadeType.REMOVE，一是不符合业务场景要求，二是外键约束报错的概率99.9999999999...%。

5. 更新数据(CascadeType.MERGE)

  在业务上，经常会有这样一种类似的需要：查找到了一个业务实体后，要更新该实体，同时也需要更新该实体所关联的其他业务实体。在我们的例子中就是，同时需要更新Order和其所关联的Item。我们使用如下测试代码：

@Test
public void testUpdate(){
    order.setName("order1_updated");

    items.get(0).setName("item1_order1_updated");
    items.get(1).setName("item2_order1_updated");

    //代码段5
    orderRepository.save(order);
    Assert.assertEquals(1, orderRepository.count(new Specification<Order>(){
        public Predicate toPredicate(Root<Order> root, CriteriaQuery<?> cq, CriteriaBuilder cb) {
            return cb.equal(root.get("name").as(String.class), "order1_updated");
        }
    }));
    Assert.assertEquals(1, itemRepository.count(new Specification<Item>() {

        public Predicate toPredicate(Root<Item> root,CriteriaQuery<?> cq, CriteriaBuilder cb) {
            return cb.equal(root.get("name").as(String.class), "item1_order1_updated");
        }
    }));

    //代码段6
    itemRepository.save(items);
    Assert.assertEquals(1, itemRepository.count(new Specification<Item>() {
        public Predicate toPredicate(Root<Item> root,CriteriaQuery<?> cq, CriteriaBuilder cb) {
            return cb.equal(root.get("name").as(String.class), "item1_order1_updated");
        }
    }));
    Assert.assertEquals(1, orderRepository.count(new Specification<Order>(){
        public Predicate toPredicate(Root<Order> root, CriteriaQuery<?> cq, CriteriaBuilder cb) {
            return cb.equal(root.get("name").as(String.class), "order1_updated");
        }
    }));
}

  在该场景中，我们分别测试如下情况：

5.2 结论

  通过使用CascadeType.MERGE，可以说是最容易理解的，理解了上面的PERSIST和REMOVE，MERGE就没有问题。

6. 刷新数据(CascadeType.REFRESH)

  这里刷新数据，是对应在这样的业务场景下：对于业务系统，一般会存在多个用户，如果用户A取得了order和其对应的items，并且对order和items进行了修改，同时用户B也做了如此操作，但是用户B先保存了，然后用户A保存时，需要先刷新order关联的items，然后再把用户A的变更更新到数据库。这中场景就对应了CascadeType.REFRESH的需求。