JPA双向@OneToMany未配置mappedBy时的关联持有方与原理问询

核心判定基础规则 #

• 所有双向关联永远只有1个持有方（owner），持有方的核心判定标准是：负责维护数据库中外键关联关系的一侧，JPA只会根据持有方的属性状态生成对应关联更新的SQL。
• mappedBy属性的本质是显式声明「当前这一侧是非持有方」，属性值填的是对方实体中指向当前实体的关联属性名，相当于告诉JPA：“这个关联的维护权在对面的属性上，我这边只是反向映射的查询视图，不要根据我这边的状态更新数据库关联关系”。
• 为什么@ManyToOne没有mappedBy配置项？因为对于一对多/多对一的双向关联，外键是存储在「多」那一侧的数据库表上的，天然@ManyToOne标注的这一侧就是默认持有方——外键就在它对应的表里，它不可能作为非持有方存在，因此不需要提供mappedBy配置。

测试场景问题解答 #

1. 未配置mappedBy时的关联持有方判定 #

你当前的代码既没有在Client的@OneToMany上配置mappedBy，也没有在任何一侧加@JoinColumn显式指定外键列，这种情况下JPA不会把它识别成预期的「一对多双向关联」，而是会判定为两个独立的无关联单向关系：

• 一侧是Demand类上的@ManyToOne关联：JPA会默认在demand表生成client_id外键列指向client表主键，这一侧本身是这个单向多对一关联的持有方，但因为你从未给demand对象的client属性赋值，这个外键列会一直是空值。
• 另一侧是Client类上的@OneToMany关联：因为你没有配置mappedBy声明它是非持有方，JPA会默认把它当成独立的单向一对多关联，而单向一对多的默认实现就是用第三张中间表维护关联关系——这就是你看到启动时自动创建中间表的原因，这一侧此时也成了这个单向一对多关联的持有方。

简单说，你当前写的根本不是双向关联，是两个互不干扰的单向关联，两边各自是自己所属关联的持有方，因此才会出现多余的中间表。

2. mappedBy的工作原理与运行机制 #

你可以把mappedBy理解成关联关系的「权责声明」，运行时的逻辑可以拆解为三点：

1. 当你在Client的@OneToMany上加上mappedBy = "client"时，就等于明确告知JPA：

   我这个List<Demand> demand属性只是反向查询的映射，我和Demand的一对多关系，是由Demand类里名为client的@ManyToOne属性负责维护的，外键存在demand表的client_id列，不需要为我创建中间表。

2. 加完这个配置后，整个双向关联的唯一持有方就是Demand类的client属性，此时运行逻辑会发生两个核心变化：
   • 不会再生成多余的中间关联表，关联关系完全通过demand表的client_id外键维护
   • JPA只会根据Demand.client的属性值更新外键：如果你像测试代码里那样只给client设置demand列表，但是不给每个demand对象设置client属性，事务提交时根本不会执行任何外键更新SQL，后续查出来的client.getDemand()会是空列表。
3. 回到你当前的测试代码，因为没配mappedBy，JPA会为Client侧的单向@OneToMany生成一张类似client_demand的中间表，存储client_id和demand_id的映射关系，你调用client.setDemand(...)提交时，JPA只会往这张中间表里插入关联记录，根本不会更新demand表上的client_id外键——你看起来关联设置成功了，实际数据存到了多余的中间表里，和Demand侧的@ManyToOne关联完全脱节。

正确的一对多双向关联写法 #

你只需要修改Client类的@OneToMany注解即可：

@OneToMany(mappedBy = "client")
private List<Demand> demand;

修改后要注意，维护关联关系必须给持有方赋值，也就是你在设置client的demand列表时，必须同步给每个demand设置client属性，否则外键不会更新：

entityManager.getTransaction().begin();
client.setDemand(Arrays.asList(demand1, demand2, demand3));
// 必须给持有方属性赋值，否则外键不会持久化
demand1.setClient(client);
demand2.setClient(client);
demand3.setClient(client);
entityManager.getTransaction().commit();

修改完成后就不会生成多余的中间表，关联关系会正确落到demand表的client_id外键上。

内容的提问来源于stack exchange，提问作者Yuri Bittencourt