这个问题不是关于堆污染如何发生的。这个问题不是关于注释@SafeVarargs有什么作用。据我所知，它用于抑制本地和调用站点的警告。我读了documentation 。我的问题是:为什么要将此注释添加到 Java 语言中？
考虑以下因素:
缺少注释并不是一个有用的区别。永远不会出现您打算以不安全的方式使用 VarArgs 的情况，即“UnsafeVarargs”。
这与其他注释(例如
@Override)不同，其中缺少注释是一个有用的区别:“嘿，我不打算覆盖我的父类(super class)中的任何方法，如果有人添加了一个方法，请警告我与我的父类(super class)具有相同签名的方法。”程序员要么知道如何安全地使用 Varargs，要么不知道。即使他们添加注释也不会改变这一点。那么这不是给调用者提供了一种错误的安全感吗？
这让我想起了一个有缺陷的想法，即关门时握住车门 Handlebars 会阻止您将 key 锁在里面。
继续第 2 点，默认情况下全局禁用警告，然后在进行广泛审查时全局重新启用它不是更好吗？
也许我错过了一些东西。也许注释在从旧版本 Java 迁移时发挥了有用的作用？我欢迎您的回答。谢谢。
最佳答案
从第 2 点继续，默认情况下全局禁用警告，然后在进行广泛审查时全局重新启用它不是更好吗？
对于现实来说，这听起来确实是一件糟糕的事情。
实际上，您努力推行零容忍政策。代码中的零浪费、零警告、零错误、零单元测试失败。而且你一直在检查你的“计数”。您向类添加 5 行代码；那个类(class)得到了黄色! (eclipse 告诉你那里有警告)...你进去并立即修复它们。而不是在某个假设的 future 时间点，当有人碰巧在全局范围内启用警告时。
换句话说:您甚至从未考虑全局禁用警告。
因此，反过来说:有时编译器只能检测到:“可能存在问题”，然后编译器会更好地对此发出警告。但对于程序员可以合理评估情况的情况，此类注释是一种简单、直接的方法(在真正的本地范围内工作!)来抑制编译器警告。
但是您的假设肯定是正确的，即不理解可变参数的程序员也可能会无意中以错误的方式使用该注释。一个合理的解决策略可能是:例如“让代码审查重点关注使用此注释的代码”。而不是全局禁用警告。
关于java - @SafeVarargs 注释的存在/不存在真的是一个有用的区别吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40892526/