使用序列化类的私有方法巧妙解决部分属性持久化问题
业务场景
一个计税系统和人力资源系统（HR系统）通过RMI（Remote Method Invocation，远程方法调用）对接，计税系统需要从HR系统获得人员的姓名和基本工资，以作为纳税的依据，而HR系统的工资分为两部分：基本工资和绩效工资，基本工资没什么秘密，根据工作岗位和年限自己都可以计算出来，但绩效工资却是保密的，不能泄露到外系统
方案(1) transient关键字
- 在bonus前加上transient关键字,这是一个方法，但不是一个好方法，加上transient关键字就标志着Salary类失去了分布式部署的功能，它可是HR系统最核心的类了，一旦遭遇性能瓶颈，想再实现分布式部署就不可能了，此方案否定。
方案(2) 新增业务对象
- 增加一个Person4Tax类，完全为计税系统服务，就是说它只有两个属性：姓名和基本工资。符合开闭原则，而且对原系统也没有侵入性，只是增加了工作量而已。这是个方法，但不是最优方法。
方案(3) 请求端过滤
- 在计税系统获得Person对象后，过滤掉Salary的bonus属性，方案可行但不合规矩，因为HR系统中的Salary类安全性竟然让外系统（计税系统）来承担，设计严重失职。
方案(4) 变更传输契约
- 例如改用XML传输，或者重建一个Web Service服务。可以做，但成本太高。
优秀方案
- 实现了Serializable接口的类可以实现两个私有方法：writeObject和readObject，以影响和控制序列化和反序列化的过程。 如下
public class Salary implements Serializable {
private static final long serialVersionUID = -2140234769839131214L;
// 脚本工资
private Double basePay;
// 绩效工资
private Double bonus;
public Salary(Double basePay, Double bonus) {
this.basePay = basePay;
this.bonus = bonus;
}
// 省略 get set 方法
}
public class People implements Serializable {
private static final long serialVersionUID = -2092465505451534820L;
//姓名
private String name;
// 绩效
private Salary salary;
public People(String name, Salary salary) {
this.name = name;
this.salary = salary;
}
//序列化委托方法
private void writeObject(java.io.ObjectOutputStream out) throws IOException {
out.defaultWriteObject();
out.writeDouble(salary.getBasePay());
}
// 反序列化委托方法
private void readObject(java.io.ObjectInputStream in) throws IOException,ClassNotFoundException {
in.defaultReadObject();
salary = new Salary(new Double(0),in.readDouble());
}
}
public static void main(String[] args) {
Salary salary = new Salary(new Double(4000),new Double(5000));
People people = new People("zhangsan", salary);
System.out.println(JSONObject.toJSONString(people));
byte[] data = SerializationUtils.serialize(people);
People result = (People)SerializationUtils.deserialize(data);
System.out.println(JSONObject.toJSONString(result));
}
打印结果
{“name”:”zhangsan”,”salary”:{“basePay”:4000.0,”bonus”:5000.0}}
{“name”:”zhangsan”,”salary”:{“basePay”:0.0,”bonus”:4000.0}}
使用序列化实现对象的拷贝
业务场景
如果一个项目中有大量的对象是通过拷贝生成的，那我们该如何处理？每个类都写一个clone方法，并且还要深拷贝？想想看这是何等巨大的工作量呀，是否有更好的方法呢？
- 其实，可以通过序列化方式来处理，在内存中通过字节流的拷贝来实现，也就是把母对象写到一个字节流中，再从字节流中将其读出来，这样就可以重建一个新对象了，该新对象与母对象之间不存在引用共享的问题，也就相当于深拷贝了一个新对象，代码如下：
public class CloneUtils {
@SuppressWarnings("unchecked")
public static T clone(T obj) {
T cloneObj = null;
try {
// 读取对象字节数据
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(obj);
oos.close();
// 分配内存 写入原始对象 生成新对象
ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bis);
cloneObj= (T)ois.readObject();
ois.close();
} catch (Exception ex) {
ex.printStackTrace();
}
return cloneObj;
}
}
此工具类要求被拷贝的对象必须实现Serializable接口，否则是没办法拷贝的（当然，使用反射那是另外一种技巧） 用此方法需要注意两点:
- 对象的内部属性都是可序列化的
如果有内部属性不可序列化，则会抛出序列化异常，这会让调试者很纳闷：生成一个对象怎么会出现序列化异常呢？从这一点来考虑，也需要把CloneUtils工具的异常进行细化处理。 - 注意方法和属性的特殊修饰符
比如final、static变量的序列化问题会被引入到对象拷贝中来（参考第1章），这点需要特别注意，同时transient变量（瞬态变量，不进行序列化的变量）也会影响到拷贝的效果。
当然，采用序列化方式拷贝时还有一个更简单的办法，即使用Apache下的commons工具包中的SerializationUtils类，直接使用更加简洁方便。
边界 边界 还是边界
@Test
public void 边界测试() {
Integer intMaxNum= 2147483647;
intMaxNum += 1;
int limit = 10;
// 超过边界 判断失效
if(intMaxNum < limit) {
System.out.println("数字"+intMaxNum+"小于" + limit);
}
}
输出结果
数字-2147483648小于10
莫让四舍五入亏了一方
四舍五入。四舍五入是一种近似精确的计算方法，在Java5之前，我们一般是通过使用Math.round来获得指定精度的整数或小数的，这种方法使用非常广泛，
代码如下：
public static void main (String[] args) {
System.out.println("10.5近似值：" + Math.round(10.5));
System.out.println("-10.5近似值：" + Math.round(-10.5));
}
输出结果
10.5近似值：11
-10.5近似值：-10
这是四舍五入的经典案例，也是初级面试官很乐意选择的考题，绝对值相同的两个数字，近似值为什么就不同了呢？这是由Math.round采用的舍入规则所决定的（采用的是正无穷方向舍入规则，后面会讲解）。我们知道四舍五入是有误差的：其误差值是舍入位的一半。
我们以舍入运用最频繁的银行利息计算为例来阐述该问题。
我们知道银行的盈利渠道主要是利息差，从储户手里收拢资金，然后放贷出去，其间的利息差额便是所获得的利润。对一个银行来说，对付给储户的利息的计算非常频繁，人民银行规定每个季度末月的20日为银行结息日，一年有4次的结息日。
场景介绍完毕，我们回过头来看四舍五入，小于5的数字被舍去，大于等于5的数字进位后舍去，由于所有位上的数字都是自然计算出来的，按照概率计算可知，被舍入的数字均匀分布在0到9之间，下面以10笔存款利息计算作为模型，以银行家的身份来思考这个算法：
- 四舍。舍弃的数值：0.000、0.001、0.002、0.003、0.004，因为是舍弃的，对银行家来说，就不用付款给储户了，那每舍弃一个数字就会赚取相应的金额：0.000、0.001、0.002、0.003、0.004。
- 五入。进位的数值：0.005、0.006、0.007、0.008、0.009，因为是进位，对银行家来说，每进一位就会多付款给储户，也就是亏损了，那亏损部分就是其对应的10进制补数：0.005、0.004、0.003、0.002、0.001。
因为舍弃和进位的数字是在0到9之间均匀分布的，所以对于银行家来说，每10笔存款的利息因采用四舍五入而获得的盈利是：
0.000+0.001+0.002+0.003+0.004-0.005-0.004-0.003-0.002-0.001=-0.005 也就是说，每10笔的利息计算中就损失0.005元，即每笔利息计算损失0.0005元，这对一家有5千万储户的银行来说（对国内的银行来说，5千万是个很小的数字），每年仅仅因为四舍五入的误差而损失的金额是：
public static void main (String[] args) {
//银行账户数量，5千万
int accountNum =5000*10000;
//按照人行的规定，每个季度末月的20日为银行结息日
double cost=0.0005*accountNum*4;
System.out.println("银行每年损失的金额："+cost);
}
输出结果
银行每年损失的金额：100000.0
即，每年因为一个算法误差就损失了10万元，事实上以上的假设条件都是非常保守的，实际情况可能损失得更多。那各位可能要说了，银行还要放贷呀，放出去这笔计算误差不就抵消掉了吗？不会抵销，银行的贷款数量是非常有限的，其数量级根本没有办法和存款相比。
这个算法误差是由美国银行家发现的（那可是私人银行，钱是自己的，白白损失了可不行），并且对此提出了一个修正算法，叫做银行家舍入（Banker’s Round）的近似算法，其规则如下：
- 舍去位的数值小于5时，直接舍去；
- 舍去位的数值大于等于6时，进位后舍去；
- 当舍去位的数值等于5时，分两种情况：5后面还有其他数字（非0），则进位后舍去；若5后面是0（即5是最后一个数字），则根据5前一位数的奇偶性来判断是否需要进位，奇数进位，偶数舍去。
以上规则汇总成一句话：
四舍六入五考虑，五后非零就进一，五后为零看奇偶，五前为偶应舍去，五前为奇要进一。
我们举例说明，取2位精度：
round(10.5551)=10.56
round(10.555)=10.56
round(10.545)=10.54
要在Java5以上的版本中使用银行家的舍入法则非常简单，直接使用RoundingMode类提供的Round模式即可，示例代码如下：
public static void main (String[] args) {
//存款
BigDecimal d=new BigDecimal(888888);
//月利率，乘3计算季利率
BigDecimal r=new BigDecimal(0.001875*3);
//计算利息
BigDecimal i=d.multiply(r).setScale(2,RoundingMode.HALF_EVEN);
System.out.println("季利息是："+i);
}
输出结果
季利息是：4999.99
在上面的例子中，我们使用了BigDecimal类，并且采用setScale方法设置了精度，同时传递了一个RoundingMode.HALF_EVEN参数表示使用银行家舍入法则进行近似计算，BigDecimal和RoundingMode是一个绝配，想要采用什么舍入模式使用RoundingMode设置即可。目前Java支持以下七种舍入方式：
- ROUND_UP：远离零方向舍入。
向远离0的方向舍入，也就是说，向绝对值最大的方向舍入，只要舍弃位非0即进位。 - ROUND_DOWN：趋向零方向舍入。
向0方向靠拢，也就是说，向绝对值最小的方向输入，注意：所有的位都舍弃，不存在进位情况。 - ROUND_CEILING：向正无穷方向舍入。
向正最大方向靠拢，如果是正数，舍入行为类似于ROUND_UP；如果为负数，则舍入行为类似于ROUND_DOWN。注意：Math.round方法使用的即为此模式。 - ROUND_FLOOR：向负无穷方向舍入。
向负无穷方向靠拢，如果是正数，则舍入行为类似于ROUND_DOWN；如果是负数，则舍入行为类似于ROUND_UP。 - HALF_UP：最近数字舍入（5进）。
这就是我们最最经典的四舍五入模式。 - HALF_DOWN：最近数字舍入（5舍）。
在四舍五入中，5是进位的，而在HALF_DOWN中却是舍弃不进位。 - HALF_EVEN：银行家算法。
在普通的项目中舍入模式不会有太多影响，可以直接使用Math.round方法，但在大量与货币数字交互的项目中，一定要选择好近似的计算模式，尽量减少因算法不同而造成的损失。
