Java 世界里进行并发编程有 Future 和  ExecutorService(当成 ThreadPool 来对待)，及至 Java 8 引入了更为趁手的 CompletableFuture。那么使用 Scala 该如何进行并发编程呢？Scala 能毫无障碍的使用 Java 类库，所以完全可以用 Java 的 API 来使用线程池，只是那不太 Scala 罢了。

既然是 Scala, 就尽量写成 Scala Style 吧，Scala 也有自己的 Future, 还有 Promise 呢? 至于 Promise 与 Future 多大区别，语义上似乎也差不多，只看到 Promise 中有一个 Future 的属性。如果想玩得高级一点的话就该把  Actor 弄起来，它算是所谓的纤程，多个  Actor 可跑在同一个线程中，当然启动要快，内存消耗少，还避免了上下文切换。

这里还是先体验 Scala Future 的用法。Future 本身只是描述了一个任务，及将要获得的结果(或执行的动作)，因此那样一个任务也是要放到线程池中去执行。这和 Java 的 Future/ThreadPool 是一样的概念。稍有不同的是线程池的创建与使用，线程池的默认大小配置等。看个简单的应用示例，本次测试的 Scala 版本是 2.11.12，为了突出实际的线程池大小，我们把任务数设置为 20 个

Scala Future 并发编程体验

探索是否能以流式写数据到 S3

通常，在我们项目中用 Java 代码上传数据到 S3 是下面那样的操作

AmazonS3 s3Client = AmazonS3ClientBuilder.defaultClient();

s3Client.putObject("bucket_name", "s3key.txt", new ByteArrayInputStream("hello".getBytes()), new ObjectMetadata()); //ObjectMetadata 没什么特别的话可以为 null

虽然  putObject() 的第三个参数是一个流，但它是输入流, 并非输出流啊。也就是说在执行该方法时必须把所有待上传的上据全部准备在这个输入流中，所以这里就直接用一个 ByteArrayInputStream 来包裹需上入到 S3 的数据内容。

当然 putObject() 也就无法像 FileObjectOutputStream 那样流式写入内容到文件中，因为 putObject() 前后都没有与 bucket 上那个文件上有联系。即使是用 PipedInputStream/PipedOutputStream  也不行, 比如说下面的代码 Read More

上一次关注 Scala 新版本特性还是在将近五年前，针对的是  Scala 2.10. 后来也一直在使用 Scala，基本上是 Scala 2.11， 但对 Scala 2.11 所带来的新特性基本无知，大约有个 Macro 功能，没什么机会用上，应用 sbt 时稍有接触。还是老句老话， 了解新特性最可靠的文档是每个版本的的 Release Notes, 比如 Scala 2.12.0 Release Notes.

其中 Scala 2.12 带来的主要特性在于对 Java 8 的充分支持：

1. Scala 可以有方法实现的 trait 直接编译为带默认方法的 Java 接口
2. Lambda 表达式无需生成相应的类，而是用到 invokedynamic 字节码指令(这个是 Java 7 加进来的新指令)
3. 最方便的功能莫过于终于支持 Java  8 风格的 Lambda，即功能性接口的 SAM(Single Abstract Method)

Scala 的 Lambda 内部实现

这儿主要是体验 Scala 2.12 如何使用 Java 8 风格的 Lambda. 在 Scala 2.12 之前，Scala 对 Lambda 的支持是为你准备了一大堆的 trait 类，有

1. Function0, Function1, ...... Function22 (接收多个参数，返回一个值)
2. Product1, Product2, ...... Product22 (函数返回多个值，即 TupleX 时用的)

第一次用  spark-submit 提交任务，是 Scala 的程序，命令格式是

spark-submit --class <main-class> --master local[*] --name "My first Spark Job" spark-test-fat-1.0-SNAPSHOT.jar

结果报出错误

Exception in thread "main" java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:330)
at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:263)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:318)
......
at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:119)
at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)

Google 查了下，是需要把 jar 文件中的 META-INF/*.RSA META-INF/*.DSA META-INF/*.SF 文件清理掉。我们可以执行如下命令从现有的 jar 中除去

zip -d <jar file name>.jar META-INF/*.RSA META-INF/*.DSA META-INF/*.SF

是因为 jar 包中包含有这些文件才造成提交 Spark 时验证文件签名摘要时失败。 Read More

在 Java 测试中使用 Mockito 有段时日了，以前只是想当然的认为 Mock 的对象属性值和方法返回值都是依据同样的规则。基本类型是 0, 0.0, 或 false, 对象类型都是 null, Mock 对象的默认返回值也应该是一样的。直到最近有一天，有一个返回 Optional<String> 类型的方法，由于忘记对该方法打桩，意外的发现它返回的不是 null, 而 Optional.empty(), 因此才意识到此处定有蹊跷。着实有必要用代码验证一下 Mockito 是怎么决定属性及方法的各种返回类型的默认值的。

此次测试所用的 Mockito 版本是 mockito-core-2.12.0.

于是创建了下面一个类 MyClass 用于生成 Mock 对象，选取了一些典型的数据类型, 包括 int, Double, String, long[], Optional<String>, Collection<String>, Map<String, String>, 同时测试 Mock 对象默认的属性值与方法默认返回值。 Read More

Spring 相关代码分析

1@SpringBootApplication
2@ComponentScan(basePackages = "cc.unmi")
3public class DemoApplication {
4    public static void main(String[] args) {
5        SpringApplication.run(DemoApplication.class, args);
6    }
7}