使用@SuppressWarnings("unchecked") 时的性能注意事项

Question

希望你一切都好。

这post是关于在检索数据库信息时使用@SuppressWarnings("unchecked") 时的性能考虑。我带着一个问题来问我公司的领导，这似乎是一个灰色地带。例子如下

场景 1：

public List<BusinessObject> retrieveInformation(Long id){
    List<? extends Object> info = persistenceService.get("namedQuery", params, values);
    //... cast the contents one by one to List<BusinessObject> and return
}

场景 2：

public List<BusinessObject> retrieveInformation(Long id){
    List<?> info = persistenceService.get("namedQuery", params, values);
    //... cast the contents one by one to List<BusinessObject> and return
}

场景 3：

public List<BusinessObject> retrieveInformation(Long id){
    List<BusinessObject> info = (List<BusinessObject>)persistenceService.get("namedQuery", params, values);
    //... return the List<BusinessObject>
}

场景 4：

@SuppressWarnings("unchecked") 
public List<BusinessObject> retrieveInformation(Long id){
    List<BusinessObject> info = persistenceService.get("namedQuery", params, values);
    //... return the List<BusinessObject>
}

当然，还有很多方法可以做到这一点，但我关心的是如何以最佳性能完成这个过程。因此，我们需要考虑到，在检索信息时，我们可能会在查询中出错，并且会出现异常；另外，如果没有这样的错误，我们就已经知道将要检索的对象的类型。

所以，从一个大的商业项目的角度来考虑这个问题，所有的组件都到位了，比如 hibernate 层、DAO 和 DTO，你能帮我确定一下吗：

具有最佳性能考虑的一个选项。
如果@SuppressWarnings("unchecked")注解有性能方面的考虑。
如果在此范围内摆脱@SuppressWarnings("unchecked") 是一个很好的做法。

祝你有愉快的一天。

Answer 1

据我所知，@SuppressWarnings 注释对性能没有影响。它们不会实质性地改变生成的字节码。

字节码编译器应省略源代码中不必要的类型转换，但编译器将包含确保运行时类型安全所必需的任何类型转换，而不管警告是否被抑制¹。

此外，如果（假设）编译器确实插入了一些并非绝对必要的类型转换字节码，它们应该由 JIT 编译器优化掉。

但是，最好编写您的代码，这样您就不需要使用 @SuppressWarnings 注释。问题是注释可以隐藏代码中的逻辑错误；即警告可能是真实的。如果未通过彻底的单元和集成测试检测到，这些可能会导致意外的运行时错误。

^{1 - 如果编译器不这样做，那么字节码在被 JVM 加载时将无法通过验证。}

Answer 2

@SuppressWarnings 只影响编译器，并且只会阻止编译器显示警告。

当分配给泛型列表时，所发生的只是编译器有机会验证类型的兼容性。在运行时间，泛型信息被删除。

场景 3 是最好的选择，假设从代码质量的角度来看，您正在从调用中获得一个列表。所有四种情况都会产生相同的输出。

使用@SuppressWarnings("unchecked") 时的性能注意事项

Performance considerations when using @SuppressWarnings("unchecked")

java

performance

warnings

query-performance