我希望你很好。
这篇文章是关于在检索数据库信息时使用 @SuppressWarnings("unchecked") 时的性能考虑。我带着一个问题向我公司的领导提出了问题，这似乎是灰色地带。示例如下。
场景一：
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>
}
当然，有很多方法可以做到这一点，但我关心的是一种以最佳性能执行此过程的方法。因此，我们需要考虑到在检索信息时，我们可能会在查询中出现错误，并且会出现异常；此外，如果没有这样的错误，我们已经知道将要检索的对象的类型。
所以，从一个大的商业项目的角度考虑这个问题，所有的组件都到位，比如休眠层、DAO 和 DTO，请你帮我确定：
祝你今天过得愉快。
据我所知，@SuppressWarnings注释对性能没有影响。它们不会实质性地改变生成的字节码。
字节码编译器应省略源代码中不必要的类型转换，但编译器将包括确保运行时类型安全所需的任何类型转换，而不管警告1 是否被抑制。
此外，如果（假设）编译器确实插入了一些不是绝对必要的类型转换字节码，它们应该由 JIT 编译器优化掉。
但是，最好编写您的代码，这样您就不需要使用@SuppressWarnings注释。问题是注释可以隐藏代码中的逻辑错误；即警告可能是真实的。如果没有被彻底的单元和集成测试检测到，这些可能会导致意外的运行时错误。
1 - 如果编译器没有这样做，那么字节码在被 JVM 加载时将无法通过验证。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句