复用JPA Specification实现分组统计 解决表重复关联问题

问题根因 #

原有代码执行顺序为先调用spec.toPredicate生成查询条件，你的Specification内部已经为了构造过滤规则关联了inwardOutwardList、product等关联表，后续你再手动执行join操作时，JPA不会自动识别复用已存在的关联，就会生成重复的join语句，最终导致统计结果异常。

解决方案 #

方案1：数据库层面聚合（适合大数据量场景） #

调整关联创建顺序，先创建需要用到的关联再调用Specification生成条件，Specification会自动复用已存在的关联，不会重复生成join语句。
首先编写工具方法获取或创建关联，避免重复关联：

// 工具方法：获取根对象中已存在的关联，不存在则新建
private <X, Y> Join<X, Y> getOrCreateJoin(Root<X> root, String attributeName) {
    for (Join<X, ?> join : root.getJoins()) {
        if (join.getAttribute().getName().equals(attributeName)) {
            return (Join<X, Y>) join;
        }
    }
    return root.join(attributeName);
}

// 重载方法：支持从Join对象中获取/创建子关联
private <X, Y> Join<X, Y> getOrCreateJoin(Join<X, ?> parent, String attributeName) {
    for (Join<?, ?> join : parent.getJoins()) {
        if (join.getAttribute().getName().equals(attributeName)) {
            return (Join<X, Y>) join;
        }
    }
    return parent.join(attributeName);
}

调整你的查询方法逻辑：

@Service
@Transactional
public class GroupBySpecification {
    @Autowired
    EntityManager entityManager;
    @Autowired
    InwardInventoryRepo inwardInventoryRepo;

    Logger log = LoggerFactory.getLogger(GroupBySpecification.class);

    public List<ProductGroupedDAO> findDataByConfiguration(Specification<InwardInventory> spec) {
        CriteriaBuilder builder = entityManager.getCriteriaBuilder();
        CriteriaQuery<ProductGroupedDAO> query = builder.createQuery(ProductGroupedDAO.class);
        Root<InwardInventory> root = query.from(InwardInventory.class);

        // 先创建需要用到的关联，后续Specification会自动复用
        Join<InwardInventory, InwardOutwardList> ioList = getOrCreateJoin(root, InwardInventory_.INWARD_OUTWARD_LIST);
        Join<InwardOutwardList, Product> productList = getOrCreateJoin(ioList, InwardOutwardList_.PRODUCT);

        // 再调用Specification生成查询条件，不会重复创建关联
        Predicate p = spec.toPredicate(root, query, builder);
        query.where(p);

        query.multiselect(
                productList.get(Product_.PRODUCT_NAME),
                productList.get(Product_.MEASUREMENT_UNIT),
                builder.sum(ioList.get(InwardOutwardList_.QUANTITY))
        );
        query.groupBy(
                productList.get(Product_.PRODUCT_NAME),
                productList.get(Product_.MEASUREMENT_UNIT)
        );

        return entityManager.createQuery(query).getResultList();
    }
    // 上面的两个getOrCreateJoin工具方法放在这里
}

方案2：内存层面聚合（适合小数据量场景，开发成本极低） #

完全复用已有的Specification逻辑，将符合条件的所有数据加载到内存后做分组聚合，无需修改任何查询逻辑，稳定性最高。

public List<ProductGroupedDAO> groupInMemory(Specification<InwardInventory> spec) {
    // 复用原有Repository逻辑，传入unpaged获取所有符合条件的入库单
    List<InwardInventory> allMatchRecords = inwardInventoryRepo.findAll(spec, Pageable.unpaged()).getContent();

    // 流式处理展开明细、过滤逻辑删除、分组求和
    Map<Map.Entry<String, String>, Double> sumResult = allMatchRecords.stream()
            .flatMap(inwardInventory -> inwardInventory.getInwardOutwardList().stream())
            // 过滤逻辑删除的明细，可根据你的实际字段调整
            .filter(item -> !item.getIsDeleted())
            .collect(Collectors.groupingBy(
                    item -> Map.entry(
                            item.getProduct().getProductName(),
                            item.getProduct().getMeasurementUnit()
                    ),
                    Collectors.summingDouble(InwardOutwardList::getQuantity)
            ));

    // 转换为DAO返回
    return sumResult.entrySet().stream()
            .map(entry -> new ProductGroupedDAO(
                    entry.getKey().getKey(),
                    entry.getKey().getValue(),
                    entry.getValue()
            ))
            .toList();
}

方案选择建议 #

• 若筛选后数据量在万级以下，优先选内存聚合方案，开发成本最低，完全复用已有验证过的过滤逻辑，不会出现SQL层面的错误
• 若筛选后数据量很大，选数据库聚合方案，减少内存占用，性能更好

内容的提问来源于stack exchange，提问作者Sridhar Patnaik