最近因为技改出现了很多问题。上面提到的缓存穿透只是其中之一。想了想，虽然都是比较简单的问题，但是在实践中应该还是有很多人会遇到的。不过，这些问题看似很简单，但你一定要踩下去。==和equals关于==和equals的区别，相信稍微做过一两年开发的同学应该很清楚，但是，然而，这个坑在很多开发中还是经常出现，为什么呢？因为有时候有些同学觉得没什么区别，就用==，然而，有些意外总是如期而至。不久前，由于在线RPC框架切换，我们遇到了一个小问题。本来网上的接口是这样定义的：然后在接口查询中使用了一个枚举类型，根据id获取枚举值，不过这里用==号来判断。caller的写法：本来这段代码在网上跑了两年，一点问题都没有。为什么突然失效了？但是切换框架后，这个界面报错了。当时我也是在这个地方看了半天，猜到是这里的问题，但后来想了想，好像不应该。结果最后发现原来RPC帧传输使用的是valueOf，从缓存中取值，加上自动装箱拆箱，判断可以通过。但是，新框架使用了newByte()，所以这段旧代码永远不会通过，因为这是一个新对象。查看此测试的结果。后来通过安装AlibabaJavaCodingGuidelines插件统一扫描所有代码，又发现了一个作弊问题。这种写法是不同的。该枚举只是将代码成员变量定义为字节基本类型，而不是包装类型。这样，==判断的代码又OK了。坑爹1想象一下，因为是基本数据类型，拆箱后当然要通过==判断了。还有一种比较奇葩的写法，成员变量是Byte包类型，getEnumByCode(bytecode)这里用的是基本类型。当然这种写法也可以判断为通过。坑爹2So，累死了。。。最后补充一点基本数据类型缓存的知识。可以通过==判断的原因也是依赖缓存的原因。DataTypePackagingTypeCacheTypeCacheValueRangebyteByteByteCache-128~127shortShortShortCache-128~127intIntegerIntegerCache-128~127longLongLongCache-128~127charCharacterCharacterCache0~127一万，一万，使用等于判断项目中的基本数据类型，因为即使你现在确定这段代码是正确的，鬼也不知道后面会发生什么！不要冒险。日志满了，项目技改上线后不久，发现接口成功率直接降为0（降为0的告警监控一定要有，不然不知道怎么办）死）。找了半天，发现其他一切正常。最后发现GC耗时急剧增加。当我登录服务器时，发现硬盘已满。然后果断看日志，因为我们的硬盘其实很小，我们先怀疑日志，果然日志爆了。使用ls-lht检查文件大小。通过rm-rf删除后，发现硬盘空间还没有释放。一般情况下不会出现这个问题，但是如果文件被锁定或者有其他进程正在向文件写入数据，就会出现问题。在Linux中，文件系统中存储的文件由两部分组成：指针部分：指针位于文件系统的元数据中，删除数据后，指针从元数据中清除。数据部分：而数据部分存储在磁盘中。如上面的情况，虽然我们删除了service.log，但是由于进程锁，指针部分并没有从meta-data中删除，所以我们也看到了存储空间没有释放的问题。有两种解决方法：使用lsof-n|grepdelete查看是什么进程在写service.log，通过命令发现我们的java进程一直在写文件，然后直接通过后台工具重启应用，发现重启后恢复正常。清除日志文件并执行命令echo"">/service.log。这种方式可以立即释放磁盘空间，进程继续写入日志不会受到影响。本文转载自微信公众号“爱小仙”，可通过以下二维码关注。转载本文请联系艾小仙公众号。
