在这个浮躁的社会,咱们都学会了一种技能,快速学习使用各类开源库、开源框架。html
学习使用各类高端大气的技术,热修复、插件化、模块化、ORM……java
这些技能当然重要,可是有时候也要放慢脚步,耐着性子,打打基本功。android
不要看不起这些零零碎碎的基础知识,这些基础日积月累,慢慢的会让你跟同事拉开差距。程序员
接下来,咱们直奔主题。开始咱们的基本功。web
System.out.println("1/0=" + 1/0);
复制代码
大叔的灵魂拷问:oracle
上面的代码会崩溃吗?若是不会,会输出什么呢?app
上面的代码会崩溃吗?若是不会,会输出什么呢?框架
上面的代码会崩溃吗?若是不会,会输出什么呢?模块化
运行直接崩溃。函数
咱们再来看一行代码:
System.out.println("1.0/0=" + 1.0/0);
复制代码
大叔的灵魂拷问:
会崩溃吗?若是不会,会输出什么呢?
会崩溃吗?若是不会,会输出什么呢?
会崩溃吗?若是不会,会输出什么呢?
输出日志:
为何浮点数除以0不会崩溃?
咱们先说结论:
由于java的float和double使用了IEEE 754标准。
这个标准规定:浮点数除以0等于正无穷或负无穷。
因而咱们打开Double这个类来看看。
infinity单词的意思是:无穷大
NaN是Not a Number的简称,也就是非数。
因而,咱们发现,正无穷大的定义竟然是1.0f/0.0f 。负无穷大的定义为**-1.0f/0.0f**,非数的定义为0.0f/0.0f
我继续看一个代码段:
public static void main(String[] args) {
System.out.println("1.0/0=" + 1.0/0);
System.out.println("-1.0/0=" + -1.0/0);
double positiveInfinity = 1.0/0;
double negativeInfinity = -1.0/0;
System.out.println("(positiveInfinity==negativeInfinity)=" + (positiveInfinity==negativeInfinity));
System.out.println();
System.out.println("100.0/0=" + 100.0/0);
System.out.println("-100.0/0=" + -100.0/0);
System.out.println();
System.out.println("0.0/0=" + 0.0/0);
System.out.println("(-0.0==0.0)=" + (-0.0==0.0));
}
复制代码
大叔的灵魂拷问:
上面的代码段会输出什么呢?
上面的代码段会输出什么呢?
上面的代码段会输出什么呢?
运行结果:
注意关键词1:
IEEE 754
java的单精浮点数float和双精浮点数double,符合IEEE 754标准。
IEEE 754:二进制浮点数算术标准 ,这个标准描述了浮点数的存储以及处理的一些规范。
注意关键词2
A NaN value is used to represent the result of certain invalid operations such as dividing zero by zero.
翻译过来的就是:NaN = 0.0/0.0
这也就是咱们看到Double类里面NaN的定义。
咱们把这个文档往下翻一些,会发现这么一句:
for example,
1.0/0.0
has the value positive infinity, while the value of1.0/-0.0
is negative infinity.
翻译成中文: 1.0/0.0 等于正无穷大,1.0/-0.0 等于负无穷大
因而咱们明白,浮点数除以0并不会崩溃,他是合法的,是符合IEEE 754规范。
也正是由于 IEEE 754的规范就是这么规定的,因此java才这么实现的。
下面这段来自,维基百科,en.wikipedia.org/wiki/Divisi…
咱们即便知道了,浮点数除以0不会崩溃,知道了IEEE标准,有什么用呢?
不少人都会以为,费这么大劲,理解了,浮点数除以0不会崩溃,能有什么用呢?平时咱们写代码都不会除以0。这么骚的操做,我才不会这么干。
是的,这个操做是有点骚,你不会这么干并不表明其余同事不会这么作。并且极可能你这么干了本身不知道。
在咱们写业务代码的时候,这个知识点,不多不多能用上。
可是当咱们恰好遇到除以0致使的bug的时候,这个时候就很是有用。
尤为像android的app,用户在线上遇到的bug,咱们没法复现,只能经过日志去分析排查时;
这个时候每一个程序员都是福尔摩斯,根据一行行日志线索,配合实际代码,排查问题的可能性。
若是咱们的认知是错误的,任何数除以0都会崩溃,那么咱们的分析将会直接绕过真相去推理。因而得出结论,怎么可能有bug,不可能的。
因而浪费了不少时间,去收集线索,去推翻咱们固有的认知,才能找到真相。
假如咱们一开始就有正确的常识,咱们就会少走不少弯路。
有位同事写了这么一段代码
/** * 速度换算 米/秒 * @param distance 距离,单位米 * @param time 时间,单位秒 */
float computeSpeed(float distance, long time){
return distance/time;
}
复制代码
而后有一天忽然某同事从另外一个进程获取到数据传入这个函数。
再而后,忽然有一天发现,速度显示一串很奇怪的数字。
因而……接下来的故事,便如大家所想。
本来1小时就解决的bug,花了5个小时。
也正如,blog开头的引言所表达的。不要小看这些零零碎碎的知识点。
参考资料: