刚刚讨论Streams和Java 8 Lambda功能，以及对其他不言自明的Oracle doc Lambda Expressions状态的最后评论：
如果lambda表达式的目标类型及其类型，则可以序列化它 捕获的参数是可序列化的。但是，就像内部类一样 强烈建议不要对lambda表达式进行序列化。
检查这个我发现了SO问题
OP处理来自客户端代码的序列化lambda表达式。
如果我有一个web服务，其中一个参数是一个lambda表达式，它似乎可能包含恶意代码，可以执行文件系统访问或导致堆栈溢出等事情 - 所以信任它是非常愚蠢的。
我是否过度夸大了安全风险，或者序列化表达式可以包含什么限制？
答案 0 :(得分：5)
让我们这样说：无论如何，Java对象序列化（在某种程度上）是一个安全噩梦（例如，参见here）。
换句话说：序列化本身就是一个需要首先考虑周到的话题。因此，如果你谈论序列化的lambdas或任何其他类型的序列化对象，它并不重要。
因此，例如，您希望确保理解并支持相应的规则，例如来自CERT。
答案 1 :(得分：3)
Oracle SE的Oracle安全编码指南中的一个建议是
Guideline 8-3 / SERIAL-3: View deserialization the same as object construction
本质上，应用于构造函数参数的相同验证检查也应该应用于传入的反序列化数据。通过提供执行验证的readObject方法，可以对普通对象执行此操作。但是， NOT 可以为序列化lambda提供readObject方法，因此不可能对lambda的序列化数据执行任何验证。
序列化的lambda与普通对象的序列化共享所有安全风险，但在这方面，序列化的lambdas比普通的可序列化对象遭受更广泛的安全风险。