完整的演讲充分解释了这个问题，并提出了一个很好的范式转换方法来避免这些序列化问题:https://github.com/samthebest/dump/blob/master/sams-scala-tutorial/serialization-exceptions-and-memory-leaks-no-ws.md

投票最多的答案基本上是建议抛弃整个语言特性——不再使用方法，只使用函数。的确，在函数式编程中，类中的方法应该避免，但是将它们转换为函数并不能解决设计问题(参见上面的链接)。

在这种特殊的情况下，你可以使用@transient注释告诉它不要试图序列化有问题的值(这里是Spark。ctx是一个自定义类，而不是Spark的OP命名):

@transient
val rddList = Spark.ctx.parallelize(list)

您还可以重新构造代码，使rddList存在于其他地方，但这也很麻烦。

未来可能是孢子

在将来，Scala将包括这些被称为“孢子”的东西，这将允许我们细粒度地控制闭包到底会吸引什么，不吸引什么。此外，这应该将所有意外拉入不可序列化类型(或任何不需要的值)的错误转变为编译错误，而不是现在可怕的运行时异常/内存泄漏。

http://docs.scala-lang.org/sips/pending/spores.html

关于Kryo序列化的提示

当使用kyro，使注册是必要的，这将意味着你得到错误，而不是内存泄漏:

最后，我知道kryo有kryo. setregistrationoptional (true)，但我很难弄清楚如何使用它。当打开这个选项时，如果我没有注册类，kryo似乎仍然会抛出异常。”

用kryo注册类的策略

当然，这只能提供类型级别的控制，而不是值级别的控制。

．.． 还会有更多的想法。

我用另一种方法解决了这个问题。您只需要在传递闭包之前序列化对象，然后反序列化。即使您的类不是Serializable，这种方法也很有效，因为它在幕后使用了Kryo。你只需要一些咖喱。；）

下面是我的一个例子:

def genMapper(kryoWrapper: KryoSerializationWrapper[(Foo => Bar)])
               (foo: Foo) : Bar = {
    kryoWrapper.value.apply(foo)
}
val mapper = genMapper(KryoSerializationWrapper(new Blah(abc))) _
rdd.flatMap(mapper).collectAsMap()

object Blah(abc: ABC) extends (Foo => Bar) {
    def apply(foo: Foo) : Bar = { //This is the real function }
}

你可以随心所欲地让Blah变得复杂，比如类、伴生对象、嵌套类、对多个第三方库的引用。

KryoSerializationWrapper是指:https://github.com/amplab/shark/blob/master/src/main/scala/shark/execution/serialization/KryoSerializationWrapper.scala

我也有过类似的经历。

当我在驱动程序(master)上初始化一个变量时触发了错误，但随后试图在其中一个工人上使用它。 当这种情况发生时，Spark Streaming将尝试序列化对象以将其发送给worker，如果对象不可序列化则失败。

我通过使变量为静态来解决这个错误。

以前的无效代码

  private final PhoneNumberUtil phoneUtil = PhoneNumberUtil.getInstance();

工作代码

  private static final PhoneNumberUtil phoneUtil = PhoneNumberUtil.getInstance();

学分:

https://learn.microsoft.com/en-us/answers/questions/35812/sparkexception-job-aborted-due-to-stage-failure-ta.html (pradeepcheekatla-msft的答案) https://databricks.gitbooks.io/databricks-spark-knowledge-base/content/troubleshooting/javaionotserializableexception.html

Scala类中定义的方法是不可序列化的，方法可以转换为函数来解决序列化问题。

方法的语法

def func_name (x String) : String = {
...
return x
}

函数的语法

val func_name = { (x String) => 
...
x
}

完整的演讲充分解释了这个问题，并提出了一个很好的范式转换方法来避免这些序列化问题:https://github.com/samthebest/dump/blob/master/sams-scala-tutorial/serialization-exceptions-and-memory-leaks-no-ws.md

投票最多的答案基本上是建议抛弃整个语言特性——不再使用方法，只使用函数。的确，在函数式编程中，类中的方法应该避免，但是将它们转换为函数并不能解决设计问题(参见上面的链接)。

在这种特殊的情况下，你可以使用@transient注释告诉它不要试图序列化有问题的值(这里是Spark。ctx是一个自定义类，而不是Spark的OP命名):

@transient
val rddList = Spark.ctx.parallelize(list)

您还可以重新构造代码，使rddList存在于其他地方，但这也很麻烦。

未来可能是孢子

在将来，Scala将包括这些被称为“孢子”的东西，这将允许我们细粒度地控制闭包到底会吸引什么，不吸引什么。此外，这应该将所有意外拉入不可序列化类型(或任何不需要的值)的错误转变为编译错误，而不是现在可怕的运行时异常/内存泄漏。

http://docs.scala-lang.org/sips/pending/spores.html

关于Kryo序列化的提示

当使用kyro，使注册是必要的，这将意味着你得到错误，而不是内存泄漏:

最后，我知道kryo有kryo. setregistrationoptional (true)，但我很难弄清楚如何使用它。当打开这个选项时，如果我没有注册类，kryo似乎仍然会抛出异常。”

用kryo注册类的策略

当然，这只能提供类型级别的控制，而不是值级别的控制。

．.． 还会有更多的想法。

我也遇到过类似的问题，从Grega的回答中我理解到

object NOTworking extends App {
 new testing().doIT
}
//adding extends Serializable wont help
class testing {

val list = List(1,2,3)

val rddList = Spark.ctx.parallelize(list)

def doIT =  {
  //again calling the fucntion someFunc 
  val after = rddList.map(someFunc(_))
  //this will crash (spark lazy)
  after.collect().map(println(_))
}

def someFunc(a:Int) = a+1

}

你的doIT方法试图序列化someFunc(_)方法，但由于方法是不可序列化的，它试图序列化类测试，这也是不可序列化的。

为了让你的代码工作，你应该在doIT方法中定义someFunc。例如:

def doIT =  {
 def someFunc(a:Int) = a+1
  //function definition
 }
 val after = rddList.map(someFunc(_))
 after.collect().map(println(_))
}

如果有多个函数进入图中，那么所有这些函数都应该对父上下文可用。