@SuppressWarnings注释是JDK中可用的三个内置注释之一，在Java 1.5中与@Override和@Deprecated一起添加。

@SuppressWarnings指示编译器忽略或抑制注释元素中指定的编译器警告以及该元素中的所有程序元素。 例如，如果对一个类进行了注释以抑制特定的警告，那么在该类内部的方法中生成的警告也将被分离。

您可能已经看到了@SuppressWarnings(“unchecked”)和@SuppressWarnings(“serial”)，这是@SuppressWarnings注释的两个最流行的示例。前者用于抑制由于未经检查的强制转换而产生的警告，而后者用于提醒在Serializable类中添加SerialVersionUID。

阅读更多信息:https://javarevisited.blogspot.com/2015/09/what-is-suppresswarnings-annotation-in-java-unchecked-raw-serial.html#ixzz5rqQaOLUa

一个技巧是创建一个扩展通用基础接口的接口…

public interface LoadFutures extends Map<UUID, Future<LoadResult>> {}

然后你可以在转换之前用instanceof检查它…

Object obj = context.getAttribute(FUTURES);
if (!(obj instanceof LoadFutures)) {
    String format = "Servlet context attribute \"%s\" is not of type "
            + "LoadFutures. Its type is %s.";
    String msg = String.format(format, FUTURES, obj.getClass());
    throw new RuntimeException(msg);
}
return (LoadFutures) obj;

简单地说:这是一个警告，编译器通过它表示它不能确保类型安全。

例如，JPA服务方法:

@SuppressWarnings("unchecked")
public List<User> findAllUsers(){
    Query query = entitymanager.createQuery("SELECT u FROM User u");
    return (List<User>)query.getResultList();
}

如果我没有注释@SuppressWarnings(“unchecked”)在这里，它将有一个问题与行，我想返回我的ResultList。

简单地说，类型安全的意思是:如果一个程序在编译时没有错误和警告，并且在运行时没有引发任何意外的ClassCastException，则该程序被认为是类型安全的。

我建立在http://www.angelikalanger.com/GenericsFAQ/FAQSections/Fundamentals.html上

SuppressWarning注释用于对带注释的元素禁用编译器警告。具体来说，未检查的类别允许抑制因未检查的类型强制转换而生成的编译器警告。

@SuppressWarnings注释是JDK中可用的三个内置注释之一，在Java 1.5中与@Override和@Deprecated一起添加。

@SuppressWarnings指示编译器忽略或抑制注释元素中指定的编译器警告以及该元素中的所有程序元素。 例如，如果对一个类进行了注释以抑制特定的警告，那么在该类内部的方法中生成的警告也将被分离。

您可能已经看到了@SuppressWarnings(“unchecked”)和@SuppressWarnings(“serial”)，这是@SuppressWarnings注释的两个最流行的示例。前者用于抑制由于未经检查的强制转换而产生的警告，而后者用于提醒在Serializable类中添加SerialVersionUID。

阅读更多信息:https://javarevisited.blogspot.com/2015/09/what-is-suppresswarnings-annotation-in-java-unchecked-raw-serial.html#ixzz5rqQaOLUa

有时候Java泛型就是不能让您做您想做的事情，您需要有效地告诉编译器您所做的事情在执行时是合法的。

在模拟通用接口时，我通常发现这很麻烦，但也有其他例子。通常值得尝试一种方法来避免警告，而不是抑制它(Java泛型常见问题解答在这里有所帮助)，但有时即使有可能，它也会使代码变形，以至于抑制警告会更整洁。在这种情况下，总是添加解释性评论!

相同的泛型常见问题解答有几个关于这个主题的部分，从“什么是“未检查的”警告?”-很值得一读。