java代码例子、java代码怎么写 收藏 0

Java编程中，13条优雅处理异常的最佳实践

在开发具体业务时，很多人会使用异常来控制业务逻辑，例如：

代码中的分支逻辑应该使用if-else来控制，而不是依赖异常。使用异常来控制代码逻辑不容易理解，难于维护。

很多人在开发中，遇到try语句块，后面一定会跟一个catch块，这是不对的。我们在开发中，应该只捕获那些能处理的异常，如果处理不了，就不要捕获它，继续向上抛，谁能解决谁来捕获。

像下面这段代码对于异常的处理就毫无意义：

try{

}catch (Exception e){

throw e;

}

由于现在的开发工具IDE都比较智能，当我们在写一段try-catch代码时，通常会自动生成printStackTrace()语句，例如：

需要注意的是，e.printStackTrace()并不是处理异常，很多人认为这是在打印异常信息，也是在处理异常。

但是，e.printStackTrace()表示把异常信息输出到控制台，而不是日志中。e.printStackTrace()只能在调试阶段使用，程序在线上运行时，错误的信息要通过日志输出。

我们在处理异常时，有时可能会先捕获一个异常，再抛出另一个异常。这种场景一般用于抛出一些特定的、更容易理解的业务异常。

这样做是可以的，但在抛出新的异常时，一定要把被捕获的那个异常的异常信息也带上，避免丢失异常的堆栈。例如：

受检异常的最大特点是要求调用者必须明确地处理这个异常，这其实是一种强制性的约束。所以，当代码中有一些特殊情况需要让调用者必须关注时，要使用受检异常，起到提醒的作用。

很多人知道异常需要处理，并且尝试在代码中捕获异常，因为可能有很多异常抛出，所以会同时捕获多个异常，于是有人就写出了以下代码：

以上处理方式最大的问题就是异常的捕获顺序不合理，以上形式的捕获异常，后面的MyException和IllegalArgumentException永远不会被捕获，异常一旦发生就会被Exception直接捕获了。

所以，在捕获异常时，要把范围较小的异常放到前面，对于RuntimeException、Exception和Throwable的捕获一定要放到最后。

在关于异常的处理上，很多人建议不要直接对Exception、Throwable进行捕获，因为捕获的范围太大了，会导致永远无法知道异常的具体细节。

其实有时我们可能还真的需要对Exception、甚至Throwable进行捕获，尤其是现在很多应用都微服务化了，经常会有各种RPC接口的互相调用。

我们在给外部提供一个RPC接口时，应该通过错误码的形式传递错误信息，而不是把异常抛给调用方。因为A系统的异常抛给B系统，B系统是一定处理不了的。

所以，我们往往需要在RPC接口中对Exception进行捕获，以避免异常交给外部系统。

Throwable有Error和Exception两个子类，通常我们认为Error是程序员处理不了的，所以不建议捕获。

但是有一种特殊的情况，我们可能需要捕获Error。

当我们提供RPC服务时，一旦服务被调用过程中发生了Error，如NoSuchMethodError，我们没有捕获，那么这个错误就会一直往上抛，最终被RPC框架捕获。

RPC框架捕获这个错误之后，可能会把错误日志打印到它自己的日志文件中，而不是我们应用的业务日志中。

通常RPC框架自己的日志会有很多各种超时等异常，我们很少对其进行错误监控，这就可能导致错误发生了，但我们无法察觉。

示例代码如下：

当execute方法抛出异常之后，我们在finally中再次抛出一个异常，这就导致execute方法抛出的那个异常信息完全丢失了。丢失了异常链，会给后期的问题排查带来很大的困难。

当我们想要释放一些资源时，如数据库链接、文件链接等，需要在finally中进行释放，因为finally中的代码一定会执行。

因为我们要在finally中释放资源，所以很多开发者会顺手把try-catch-finally都写上，这其实是错误的。

当我们不想处理一个异常，又想在异常发生后做一些事情的时候，不要写catch块，而是使用finally块。

我们在日常开发中会接触很多异常，JDK内置了很多异常，一些框架中也定义了自己的异常。我们也可以自定义一些业务异常，这些异常可以有一定的继承关系，方便我们快速地识别异常的原因，以及快速恢复。比如OrderCanceledException、LoginFailedException等，我们通过这些异常的名字就知道具体发生了什么。

不要在一个几百行代码外面加一个try进行异常处理，我们需要控制try的粒度，对于那些明显不会发生异常的代码，就不要把它们放到try块中。

内容摘自《深入理解Java核心技术》，作者是Hollis，张洪亮，阿里巴巴技术专家，51CTO 专栏作家，CSDN 博客专家，掘金优秀作者，《程序员的三门课》联合作者，《Java工程师成神之路》系列文章作者；热衷于分享计算机编程相关技术，博文全网阅读量数千万。

35个可以提高千倍效率的Java代码小技巧

代码优化 ，一个很重要的课题。可能有些人觉得没用，一些细小的地方有什么好修改的，改与不改对于代码的运行效率有什么影响呢？这个问题我是这么考虑的，就像大海里面的鲸鱼一样，它吃一条小虾米有用吗？没用，但是，吃的小虾米一多之后，鲸鱼就被喂饱了。

代码优化也是一样，如果项目着眼于尽快无BUG上线，那么此时可以抓大放小，代码的细节可以不精打细磨；但是如果有足够的时间开发、维护代码，这时候就必须考虑每个可以优化的细节了，一个一个细小的优化点累积起来，对于代码的运行效率绝对是有提升的。

代码优化的目标是：

• 减小代码的体积
• 提高代码运行的效率

1、尽量指定类、方法的final修饰符

带有final修饰符的类是不可派生的。在Java核心API中，有许多应用final的例子，例如java.lang.String，整个类都是final的。为类指定final修饰符可以让类不可以被继承，为方法指定final修饰符可以让方法不可以被重写。如果指定了一个类为final，则该类所有的方法都是final的。Java编译器会寻找机会内联所有的final方法，内联对于提升Java运行效率作用重大，具体参见Java运行期优化。 此举能够使性能平均提高50% 。

2、尽量重用对象

特别是String对象的使用，出现字符串连接时应该使用StringBuilder/StringBuffer代替。由于Java虚拟机不仅要花时间生成对象，以后可能还需要花时间对这些对象进行垃圾回收和处理，因此，生成过多的对象将会给程序的性能带来很大的影响。

3、尽可能使用局部变量

调用方法时传递的参数以及在调用中创建的临时变量都保存在栈中速度较快，其他变量，如静态变量、实例变量等，都在堆中创建，速度较慢。另外，栈中创建的变量，随着方法的运行结束，这些内容就没了，不需要额外的垃圾回收。

4、及时关闭流

Java编程过程中，进行数据库连接、I/O流操作时务必小心，在使用完毕后，及时关闭以释放资源。因为对这些大对象的操作会造成系统大的开销，稍有不慎，将会导致严重的后果。

5、尽量减少对变量的重复计算

明确一个概念，对方法的调用，即使方法中只有一句语句，也是有消耗的，包括创建栈帧、调用方法时保护现场、调用方法完毕时恢复现场等。所以例如下面的操作：

建议替换为：

这样，在list.size()很大的时候，就减少了很多的消耗。

6、尽量采用懒加载的策略，即在需要的时候才创建

例如：

建议替换为：

7、慎用异常

异常对性能不利。抛出异常首先要创建一个新的对象，Throwable接口的构造函数调用名为fillInStackTrace()的本地同步方法，fillInStackTrace()方法检查堆栈，收集调用跟踪信息。只要有异常被抛出，Java虚拟机就必须调整调用堆栈，因为在处理过程中创建了一个新的对象。异常只能用于错误处理，不应该用来控制程序流程。

8、不要在循环中使用try…catch…，应该把其放在最外层

除非不得已。如果毫无理由地这么写了，只要你的领导资深一点、有强迫症一点，八成就要骂你为什么写出这种垃圾代码来了。

9、如果能估计到待添加的内容长度，为底层以数组方式实现的集合、工具类指定初始长度

比如ArrayList、LinkedLlist、StringBuilder、StringBuffer、HashMap、HashSet等等，以StringBuilder为例：

（1）StringBuilder() // 默认分配16个字符的空间

（2）StringBuilder(int size) // 默认分配size个字符的空间

（3）StringBuilder(String str) // 默认分配16个字符+str.length()个字符空间

可以通过类（这里指的不仅仅是上面的StringBuilder）的来设定它的初始化容量，这样可以明显地提升性能。比如StringBuilder吧，length表示当前的StringBuilder能保持的字符数量。因为当StringBuilder达到最大容量的时候，它会将自身容量增加到当前的2倍再加2，无论何时只要StringBuilder达到它的最大容量，它就不得不创建一个新的字符数组然后将旧的字符数组内容拷贝到新字符数组中—-这是十分耗费性能的一个操作。试想，如果能预估到字符数组中大概要存放5000个字符而不指定长度，最接近5000的2次幂是4096，每次扩容加的2不管，那么：

（1）在4096 的基础上，再申请8194个大小的字符数组，加起来相当于一次申请了12290个大小的字符数组，如果一开始能指定5000个大小的字符数组，就节省了一倍以上的空间；

（2）把原来的4096个字符拷贝到新的的字符数组中去。

这样，既浪费内存空间又降低代码运行效率。所以，给底层以数组实现的集合、工具类设置一个合理的初始化容量是错不了的，这会带来立竿见影的效果。但是，注意，像HashMap这种是以数组+链表实现的集合，别把初始大小和你估计的大小设置得一样，因为一个table上只连接一个对象的可能性几乎为0。初始大小建议设置为2的N次幂，如果能估计到有2000个元素，设置成new HashMap(128)、new HashMap(256)都可以。

10、当复制大量数据时，使用System.arraycopy()命令

11、乘法和除法使用移位操作

例如：

用移位操作可以极大地提高性能，因为在计算机底层，对位的操作是最方便、最快的，因此建议修改为：

移位操作虽然快，但是可能会使代码不太好理解，因此最好加上相应的注释。

12、循环内不要不断创建对象引用

例如：

这种做法会导致内存中有count份Object对象引用存在，count很大的话，就耗费内存了，建议为改为：

因为这毫无意义，这样只是定义了引用为static final，数组的内容还是可以随意改变的，将数组声明为public更是一个安全漏洞，这意味着这个数组可以被外部类所改变。

16、尽量在合适的场合使用单例

使用单例可以减轻加载的负担、缩短加载的时间、提高加载的效率，但并不是所有地方都适用于单例，简单来说，单例主要适用于以下三个方面：

（1）控制资源的使用，通过线程同步来控制资源的并发访问

（2）控制实例的产生，以达到节约资源的目的

（3）控制数据的共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信

17、尽量避免随意使用静态变量

要知道，当某个对象被定义为static的变量所引用，那么gc通常是不会回收这个对象所占有的堆内存的，如：

此时静态变量b的生命周期与A类相同，如果A类不被卸载，那么引用B指向的B对象会常驻内存，直到程序终止。

18、及时清除不再需要的会话

为了清除不再活动的会话，许多应用服务器都有默认的会话超时时间，一般为30分钟。当应用服务器需要保存更多的会话时，如果内存不足，那么操作系统会把部分数据转移到磁盘，应用服务器也可能根据MRU（最近最频繁使用）算法把部分不活跃的会话转储到磁盘，甚至可能抛出内存不足的异常。如果会话要被转储到磁盘，那么必须要先被序列化，在大规模集群中，对对象进行序列化的代价是很昂贵的。因此，当会话不再需要时，应当及时调用HttpSession的invalidate()方法清除会话。

19、实现RandomAccess接口的集合比如ArrayList，应当使用最普通的for循环而不是foreach循环来遍历

这是JDK推荐给用户的。JDK API对于RandomAccess接口的解释是：实现RandomAccess接口用来表明其支持快速随机访问，此接口的主要目的是允许一般的算法更改其行为，从而将其应用到随机或连续访问列表时能提供良好的性能。实际经验表明，实现RandomAccess接口的类实例，假如是随机访问的，使用普通for循环效率将高于使用foreach循环；反过来，如果是顺序访问的，则使用Iterator会效率更高。可以使用类似如下的代码作判断：

foreach循环的底层实现原理就是迭代器Iterator，参见Java语法糖1：可变长度参数以及foreach循环原理。所以后半句”反过来，如果是顺序访问的，则使用Iterator会效率更高”的意思就是顺序访问的那些类实例，使用foreach循环去遍历。

20、使用同步代码块替代同步方法

这点在多线程模块中的synchronized锁方法块一文中已经讲得很清楚了，除非能确定一整个方法都是需要进行同步的，否则尽量使用同步代码块，避免对那些不需要进行同步的代码也进行了同步，影响了代码执行效率。

21、将常量声明为static final，并以大写命名

这样在编译期间就可以把这些内容放入常量池中，避免运行期间计算生成常量的值。另外，将常量的名字以大写命名也可以方便区分出常量与变量。

22、不要创建一些不使用的对象，不要导入一些不使用的类

这毫无意义，如果代码中出现”The value of the local variable i is not used”、”The import java.util is never used”，那么请删除这些无用的内容。

23、程序运行过程中避免使用反射

关于，请参见反射。反射是Java提供给用户一个很强大的功能，功能强大往往意味着效率不高。不建议在程序运行过程中使用尤其是频繁使用反射机制，特别是Method的invoke方法，如果确实有必要，一种建议性的做法是将那些需要通过反射加载的类在项目启动的时候通过反射实例化出一个对象并放入内存—-用户只关心和对端交互的时候获取最快的响应速度，并不关心对端的项目启动花多久时间。

24、使用数据库连接池和线程池

这两个池都是用于重用对象的，前者可以避免频繁地打开和关闭连接，后者可以避免频繁地创建和销毁线程。

25、使用带缓冲的输入输出流进行IO操作

带缓冲的输入输出流，即BufferedReader、BufferedWriter、BufferedInputStream、BufferedOutputStream，这可以极大地提升IO效率。

26、顺序插入和随机访问比较多的场景使用ArrayList，元素删除和中间插入比较多的场景使用LinkedList这个，理解ArrayList和LinkedList的原理就知道了

27、不要让public方法中有太多的形参

public方法即对外提供的方法，如果给这些方法太多形参的话主要有两点坏处：

1、违反了面向对象的编程思想，Java讲求一切都是对象，太多的形参，和面向对象的编程思想并不契合

2、参数太多势必导致方法调用的出错概率增加

至于这个”太多”指的是多少个，3、4个吧。比如我们用JDBC写一个insertStudentInfo方法，有10个学生信息字段要插如Student表中，可以把这10个参数封装在一个实体类中，作为insert方法的形参。

28、字符串变量和字符串常量equals的时候将字符串常量写在前面

这是一个比较常见的小技巧了，如果有以下代码：

这么做主要是可以避免空指针异常。

29、请知道，在java中if (i == 1)和if (1 == i)是没有区别的，但从阅读习惯上讲，建议使用前者

平时有人问，”if (i == 1)”和”if (1== i)”有没有区别，这就要从C/C++讲起。

在C/C++中，”if (i == 1)”判断条件成立，是以0与非0为基准的，0表示false，非0表示true，如果有这么一段代码：

C/C++判断”i==1″不成立，所以以0表示，即false。但是如果：

这样，即使开发者不小心写成了”1 = i”，C/C++编译器也可以第一时间检查出来，因为我们可以对一个变量赋值i为1，但是不能对一个常量赋值1为i。

但是，在Java中，C/C++这种”if (i = 1)”的语法是不可能出现的，因为一旦写了这种语法，Java就会编译报错”Type mismatch: cannot convert from int to boolean”。但是，尽管Java的”if (i == 1)”和”if (1 == i)”在语义上没有任何区别，但是从阅读习惯上讲，建议使用前者会更好些。

30、不要对数组使用toString()方法

看一下对数组使用toString()打印出来的是什么：

结果是：

31、不要对超出范围的基本数据类型做向下强制转型

这绝不会得到想要的结果：

我们可能期望得到其中的某几位，但是结果却是：

解释一下。Java中long是8个字节64位的，所以12345678901234在计算机中的表示应该是：

一个int型数据是4个字节32位的，从低位取出上面这串二进制数据的前32位是：

这串二进制表示为十进制1942892530，所以就是我们上面的控制台上输出的内容。从这个例子上还能顺便得到两个结论：

1、整型默认的数据类型是int，long l = 12345678901234L，这个数字已经超出了int的范围了，所以最后有一个L，表示这是一个long型数。顺便，浮点型的默认类型是double，所以定义float的时候要写成””float f = 3.5f”

2、接下来再写一句”int ii = l + i;”会报错，因为long + int是一个long，不能赋值给int

32、公用的集合类中不使用的数据一定要及时remove掉

如果一个集合类是公用的（也就是说不是方法里面的属性），那么这个集合里面的元素是不会自动释放的，因为始终有引用指向它们。所以，如果公用集合里面的某些数据不使用而不去remove掉它们，那么将会造成这个公用集合不断增大，使得系统有内存泄露的隐患。

33、把一个基本数据类型转为字符串，基本数据类型.toString()是最快的方式、String.valueOf(数据)次之、数据+””最慢

把一个基本数据类型转为一般有三种方式，我有一个Integer型数据i，可以使用i.toString()、String.valueOf(i)、i+””三种方式，三种方式的效率如何，看一个测试：

运行结果为：

1、String.valueOf()方法底层调用了Integer.toString()方法，但是会在调用前做空判断

2、Integer.toString()方法就不说了，直接调用了

3、i + “”底层使用了StringBuilder实现，先用append方法拼接，再用toString()方法获取字符串

三者对比下来，明显是2最快、1次之、3最慢。

34、使用最有效率的方式去遍历Map

遍历Map的方式有很多，通常场景下我们需要的是遍历Map中的Key和Value，那么推荐使用的、效率最高的方式是：

如果你只是想遍历一下这个Map的key值，那用”Set keySet = hm.keySet();”会比较合适一些。

35、对资源的close()建议分开操作

意思是，比如我有这么一段代码：

建议修改为：

虽然有些麻烦，却能避免资源泄露。我想，如果没有修改过的代码，万一XXX.close()抛异常了，那么就进入了cath块中了，YYY.close()不会执行，YYY这块资源就不会回收了，一直占用着，这样的代码一多，是可能引起资源句柄泄露的。而改为上面的写法之后，就保证了无论如何XXX和YYY都会被close掉。

函数式编程的 Java 编码实践：利用惰性写出高性能且抽象的代码

本文会以惰性加载为例一步步介绍函数式编程中各种概念，所以读者不需要任何函数式编程的基础，只需要对 Java 8 有些许了解即可。

程序员的梦想就是能写出 “高内聚，低耦合”的代码，但从经验上来看，越抽象的代码往往意味着越低的性能。机器可以直接执行的汇编性能最强，C 语言其次，Java 因为较高的抽象层次导致性能更低。业务系统也受到同样的规律制约，底层的数增删改查接口性能最高，上层业务接口，因为增加了各种业务校验，以及消息发送，导致性能较低。

对性能的顾虑，也制约程序员对于模块更加合理的抽象。

一起来看一个常见的系统抽象，“用户” 是系统中常见的一个实体，为了统一系统中的 “用户” 抽象，我们定义了一个通用领域模型 User，除了用户的 id 外，还含有部门信息，用户的主管等等，这些都是常常在系统中聚合在一起使用的属性:

这看起来非常棒，“用户“常用的属性全部集中到了一个实体里，只要将这个 User 作为方法的参数，这个方法基本就不再需要查询其他用户信息了。但是一旦实施起来就会发现问题，部门和主管信息需要远程调用通讯录系统获得，权限需要远程调用权限系统获得，每次构造 User 都必须付出这两次远程调用的代价，即使有的信息没有用到。比如下面的方法就展示了这种情况（判断一个用户是否是另一个用户的主管）：

为了能在上面这个方法参数中使用通用 User 实体，必须付出额外的代价：远程调用获得完全用不到的权限信息，如果权限系统出现了问题，还会影响无关接口的稳定性。

想到这里我们可能就想要放弃通用实体的方案了，让裸露的 uid 弥漫在系统中，在系统各处散落用户信息查询代码。

其实稍作改进就可以继续使用上面的抽象，只需要将 department, supervisor 和 permission 全部变成惰性加载的字段，在需要的时候才进行外部调用获得，这样做有非常多的好处：

• 业务建模只需要考虑贴合业务，而不需要考虑底层的性能问题，真正实现业务层和物理层的解耦
• 业务逻辑与外部调用分离，无论外部接口如何变化，我们总是有一层适配层保证核心逻辑的稳定
• 业务逻辑看起来就是纯粹的实体操作，易于编写单元测试，保障核心逻辑的正确性

但是在实践的过程中常会遇到一些问题，本文就结合 Java 以及函数式编程的一些技巧，一起来实现一个惰性加载工具类。

Java 8 引入了全新的函数式接口 Supplier，从老 Java 程序员的角度理解，它不过就是一个可以获取任意值的接口而已，Lambda 不过是这种接口实现类的语法糖。这是站在语言角度而不是计算角度的理解。当你了解了严格（strict）与惰性（lazy）的区别之后，可能会有更加接近计算本质的看法。

因为 Java 和 C 都是严格的编程语言，所以我们习惯了变量在定义的地方就完成了计算。事实上，还有另外一个编程语言流派，它们是在变量使用的时候才进行计算的，比如函数式编程语言 Haskell。

所以 Supplier 的本质是在 Java 语言中引入了惰性计算的机制，为了在 Java 中实现等价的惰性计算，可以这么写：

Supplier 还存在一个问题，就是每次通过 get 获取值时都会重新进行计算，真正的惰性计算应该在第一次 get 后把值缓存下来。只要对 Supplier 稍作包装即可：

通过 Lazy 来写之前的惰性计算代码：

通过这个惰性加载工具类来优化我们之前的通用用户实体：

一个简单的构造 User 实体的例子如下：

这看起来还不错，但当你继续深入使用时会发现一些问题：用户的两个属性部门和主管是有相关性，需要通过 rpc 接口获得用户部门，然后通过另一个 rpc 接口根据部门获得主管。代码如下：

但是现在 department 不再是一个计算好的值了，而是一个惰性计算的 Lazy 对象，上面的代码又应该怎么写呢？\”函子\” 就是用来解决这个问题的

快速理解：类似 Java 中的 stream api 或者 Optional 中的 map 方法。函子可以理解为一个接口，而 map 可以理解为接口中的方法。

1 函子的计算对象

Java 中的 Collection< T>，Optional< T>，以及我们刚刚实现 Lazy< T>，都有一个共同特点，就是他们都有且仅有一个泛型参数，我们在这篇文章中暂且称其为盒子，记做 Box< T>，因为他们都好像一个万能的容器，可以任意类型打包进去。

2 函子的定义

函子运算可以将一个 T 映射到 S 的 function 应用到 Box< T> 上，让其成为 Box< S>，一个将 Box 中的数字转换为字符串的例子如下：

在盒子中装的是类型，而不是 1 和 \”1\” 的原因是，盒子中不一定是单个值，比如集合，甚至是更加复杂的多值映射关系。

需要注意的是，并不是随便定义一个签名满足 Box< S> map(Function< T,S> function) 就能让 Box< T> 成为函子的，下面就是一个反例：

所以函子是比 map 方法更加严格的定义，他还要求 map 满足如下的定律，称为 函子定律（定律的本质就是保障 map 方法能如实反映参数 function 定义的映射关系）：

• 单位元律：Box< T> 在应用了恒等函数后，值不会改变，即 box.equals(box.map(Function.identity()))始终成立（这里的 equals 只是想表达的一个数学上相等的含义）
• 复合律：假设有两个函数 f1 和 f2，map(x -> f2(f1(x))) 和 map(f1).map(f2) 始终等价

很显然 Lazy 是满足上面两个定律的。

3 Lazy 函子

虽然介绍了这么多理论，实现却非常简单：

可以很容易地证明它是满足函子定律的。

通过 map 我们很容易解决之前遇到的难题，map 中传入的函数可以在假设部门信息已经获取到的情况下进行运算：

4 遇到了更加棘手的情况

我们现在不仅可以构造惰性的值，还可以用一个惰性值计算另一个惰性值，看上去很完美。但是当你进一步深入使用的时候，又发现了更加棘手的问题。

我现在需要部门和主管两个参数来调用权限系统来获得权限，而部门和主管这两个值都是惰性的值。先用嵌套 map 来试一下：

返回值的类型好像有点奇怪，我们期待得到的是 Lazy< Set< String>>，这里得到的却多了一层变成 Lazy< Lazy< Set< String>>>。而且随着你嵌套 map 层数增加，Lazy 的泛型层次也会同样增加，三参数的例子如下：

这个就需要下面的单子运算来解决了。

快速理解：和 Java stream api 以及 Optional 中的 flatmap 功能类似

1 单子的定义

单子和函子的重大区别在于接收的函数，函子的函数一般返回的是原生的值，而单子的函数返回却是一个盒装的值。下图中的 function 如果用 map 而不是 flatmap 的话，就会导致结果变成一个俄罗斯套娃–两层盒子。

单子当然也有单子定律，但是比函子定律要复杂些，这里就不做阐释了，他的作用和函子定律也是类似，确保 flatmap 能够如实反映 function 的映射关系。

2 Lazy 单子

实现同样很简单：

利用 flatmap 解决之前遇到的问题：

三参数的情况：

其中的规律就是，最后一次取值用 map，其他都用 flatmap。

3 题外话：函数式语言中的单子语法糖

看了上面的例子你一定会觉得惰性计算好麻烦，每次为了取里面的惰性值都要经历多次的 flatmap 与 map。这其实是 Java 没有原生支持函数式编程而做的妥协之举，Haskell 中就支持用 do 记法简化 Monad 的运算，上面三参数的例子如果用 Haskell 则写做：

Java 中虽然没有语法糖，但是上帝关了一扇门，就会打开一扇窗。在 Java 中可以清晰地看出每一步在做什么，理解其中的原理，如果你读过了本文之前的内容，肯定能明白这个 do 记法就是不停地在做 flatmap 。

目前为止，我们写的 Lazy 代码如下：

利用 Lazy 我们写一个构造通用 User 实体的工厂：

工厂类就是在构造一颗求值树，通过工厂类可以清晰地看出 User 各个属性间的求值依赖关系，同时 User 对象能够在运行时自动地优化性能，一旦某个节点被求值，路径上的所有属性的值都会被缓存。

虽然我们通过惰性让 user.getDepartment() 仿佛是一次纯内存操作，但是他实际上还是一次远程调用，所以可能出现各种出乎意料的异常，比如超时等等。

异常处理肯定不能交给业务逻辑，这样会影响业务逻辑的纯粹性，让我们前功尽弃。比较理想的方式是交给惰性值的加载逻辑 Supplier。在 Supllier 的计算逻辑中就充分考虑各种异常情况，重试或者抛出异常。虽然抛出异常可能不是那么“函数式”，但是比较贴近 Java 的编程习惯，而且在关键的值获取不到时就应该通过异常阻断业务逻辑的运行。

利用本文方法构造的实体，可以将业务建模上需要的属性全部放置进去，业务建模只需要考虑贴合业务，而不需要考虑底层的性能问题，真正实现业务层和物理层的解耦。

同时 UserFactory 本质上就是一个外部接口的适配层，一旦外部接口发生变化，只需要修改适配层即可，能够保护核心业务代码的稳定。

业务核心代码因为外部调用大大减少，代码更加接近纯粹的运算，因而易于书写单元测试，通过单元测试能够保证核心代码的稳定且不会出错。

仔细想想，刚刚做了这么多，目的就是一个，让签名为 C f(A,B) 的函数可以无需修改地应用到盒装类型 Box< A>和 Box< B> 上，并且产生一个 Box< C>，在函数式语言中有更加方便的方法，那就是应用函子。

应用函子概念上非常简单，就是将盒装的函数应用到盒装的值上，最后得到一个盒装的值，在 Lazy 中可以这么实现：

不过在 Java 中实现这个并没有什么用，因为 Java 不支持柯里化。

柯里化允许我们将函数的几个参数固定下来变成一个新的函数，假如函数签名为 f(a,b)，支持柯里化的语言允许直接 f(a) 进行调用，此时返回值是一个只接收 b 的函数。

在支持柯里化的情况下，只需要连续的几次应用函子，就可以将普通的函数应用在盒装类型上了，举个 Haskell 的例子如下（< *> 是 Haskell 中应用函子的语法糖, f 是个签名为 c f(a, b) 的函数，语法不完全正确，只是表达个意思）：

参考资料

• 在 Java 函数式类库 VAVR 中提供了类似的 Lazy 实现，不过如果只是为了用这个一个类的话，引入整个库还是有些重，可以利用本文的思路直接自己实现
• 函数式编程进阶：应用函子 前端角度的函数式编程文章，本文一定程度上参考了里面盒子的类比方法：https://juejin.cn/post/6891820537736069134?spm=ata.21736010.0.0.595242a7a98f3U
• 《Haskell函数式编程基础》
• 《Java函数式编程》

作者 | 悬衡

原文链接：http://click.aliyun.com/m/1000304340/

本文为阿里云原创内容，未经允许不得转载。

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com