分布式条件下Integer大小比值的问题
起因
临下班,偶然看到阿里巴巴《JAVA开发手册》中,关于整型包装类对象之间值的比较的规约,里面提到强制使用equals,而不使用==。原因众所周知,在-128 至 127,Integer 对象是在 IntegerCache.cache 产生。
所以很多人会在代码里使用去进行-128 至 127之间的数值比较。特别是一些常量,如state,status这类的常量,值通常都在100以内进行定义。感觉上是没有问题。阿里的《JAVA开发手册》里面也提到了“**这个区间内的 Integer 值可以直接使用进行判断**”。
但是,搞大数据的同学请注意了!
大数据天然是分布式的,比如spark,每个executor执行器哪怕在同一个服务器节点上,也会申请一个单独的JVM,所以,这个时候定义一个Integer哪怕是落在-128 至 127范围以内,通过“==”能得到想要的效果吗?
都在不同的JVM了,内存地址当然不一样了,所以答案很显然是否定的。
动机
鉴于阿里巴巴的影响力,它的《JAVA开发手册》读者还有众多的。所以,觉得有必要提醒出这一点。
1.在大数据分布式情况下,对于 Integer var = ? 在-128 至 127 之间的赋值,不可以直接使用==进行判断。
2.不管是单机程序还是分布式程序,一律使用equals进行数值比较,或者使用基础数据类型。
验证
测试代码:
public class Constants {
public static final Integer STATE = 1;
}
int state = 1;
Integer state1 = 1;
Integer state2 = new Integer(1);
Integer state3 = Integer.valueOf(1);
SparkSession session = SparkSession.builder().appName("Validate").getOrCreate();
Long count = session.read().limf("/patt").select("vin").map(new MapFunction<Row, String>() {
@Override
public String call(Row value) throws Exception {
System.out.println("1 hashcode :" + System.identityHashCode(state1)+" 2:"+System.identityHashCode(state2)+" 3:"+System.identityHashCode(state3)+" constant = " + System.identityHashCode(Constants.STATE.hashCode()));
System.out.println((state == Constants.STATE) + " 1:" + (state1 == Constants.STATE) + " 2:" + (state2 == Constants.STATE) + " 3:" + (state3 == Constants.STATE));
Thread.sleep(100000);
return value.mkString();
}
}, Encoders.STRING()).count();
在不同的task打印出来的日志:
可以看到,用了Integer包装类的分布式内部比较使用“==”得不到预期值。
处理
已在github提出问题
https://github.com/alibaba/p3c/issues/863
分布式条件下Integer大小比值的问题的更多相关文章
- 【转】MySQL乐观锁在分布式场景下的实践
背景 在电商购物的场景下,当我们点击购物时,后端服务就会对相应的商品进行减库存操作.在单实例部署的情况,我们可以简单地使用JVM提供的锁机制对减库存操作进行加锁,防止多个用户同时点击购买后导致的库存不 ...
- MySQL乐观锁在分布式场景下的实践
背景 在电商购物的场景下,当我们点击购物时,后端服务就会对相应的商品进行减库存操作.在单实例部署的情况,我们可以简单地使用JVM提供的锁机制对减库存操作进行加锁,防止多个用户同时点击购买后导致的库存不 ...
- [Done]SnowFlake 分布式环境下基于ZK构WorkId
Twitter 的 Snowflake 大家应该都熟悉的,先上个图: 时间戳 序列号一般不会去改造,主要是工作机器id,大家会进行相关改造,我厂对工作机器进行了如下改造(估计大家都差不多吧,囧~~~ ...
- 虚拟机在 OpenStack 里没有共享存储条件下的在线迁移
虚拟机在 OpenStack 里没有共享存储条件下的在线迁移 本文尝试回答与 Live migration 相关的几个问题:Live migration 是什么?为什么要做 Live migratio ...
- 分布式架构下,session共享有什么方案么?
分布式架构下,session共享有什么方案么? 会点代码的大叔 科技领域创作者 分布式架构下的session共享,也可以称作分布式session一致性:关于这个问题,和大家说一说解决方案(如果有其他的 ...
- 分布式架构下的会话追踪实践【基于Cookie和Redis实现】
分布式架构下的会话追踪实践[基于Cookie和Redis实现] 博客分类: NoSQL/Redis/MongoDB session共享rediscookie分布式架构session 在单台Tomcat ...
- 【无网条件下】Linux系统、jdk、redis及集群、rabbitmq、nginx、weblogic和oracle安装及配置
本篇文章为原创,仅供参考使用,如果需要文章中提到的所有软件安装包和依赖包(即data),请以博客园邮箱联系获取链接. 准备资料 软件 主要软件包版本 路径 系统镜像 CentOS-6.10-x86_6 ...
- 复杂分布式架构下的计算治理之路:计算中间件 Linkis
前言 在当前的复杂分布式架构环境下,服务治理已经大行其道.但目光往下一层,从上层 APP.Service,到底层计算引擎这一层面,却还是各个引擎各自为政,Client-Server 模式紧耦合满天飞的 ...
- 分布式场景下Kafka消息顺序性的思考
如果业务中,对于kafka发送消息异步消费的场景,在业务上需要实现在消费时实现顺序消费, 利用kafka在partition内消息有序的特点,消息消费时的有序性. 1.在发送消息时,通过指定parti ...
随机推荐
- Radius协议-学习
目录 RFC Radius 协议 Radius-学习 RADIUS协议的主要特征 客户端/服务器模式 安全的消息交互机制 良好的扩展性 AAA介绍 C/S结构 RADIUS在协议栈中的位置 RADIU ...
- ORACLE 坏块的模拟和查看
坏块的模拟和查看使用bbed工具修改数据文件的块,然后使用dbv和rman工具查看坏块. 1.创建数据:根据dbv查看没有坏块Total Pages Marked Corrupt : 0create ...
- JVM学习笔记——栈区
栈区 Stack Area 栈是运行时的单位,堆是存储单位,栈解决程序的运行问题,即程序如何执行,如何处理数据. 每个线程在创建时都创建一个该线程私有的虚拟机栈,每个栈里有许多栈帧,一个栈帧对应一个 ...
- Java初步学习——2021.09.23每日报告,第三周周四
(1)今天做了什么: (2)明天准备做什么? (3)遇到的问题,如何解决? 学习数组,编写了一个随机选牌的代码.自己最开始一直想只设置一个字符串数组,利用随机数来输出,但那样对字符串赋值会比较麻烦.可 ...
- 图解java 多线程模式 读书笔记
第1章"Single Threaded Execution模式--能通过这座桥的只有一个人" 该模式可以确保执行处理的线程只能是一个,这样就可以有效防止实例不一致. 第⒉章&quo ...
- 【数据结构与算法Python版学习笔记】图——基本概念及相关术语
概念 图Graph是比树更为一般的结构, 也是由节点和边构成 实际上树是一种具有特殊性质的图 图可以用来表示现实世界中很多有意思的事物,包括道路系统.城市之间的航班.互联网的连接,甚至是计算机专业的一 ...
- Java:NIO 学习笔记-1
Java:NIO 学习笔记-1 说明:本笔记是根据bilibili上 尚硅谷 的课程 NIO视频 而做的笔记 主要内容 Java NIO 简介 Java NIO 与 IO 的主要区别 缓冲区(Buff ...
- SpringCloud微服务实战——搭建企业级开发框架(七):自定义通用响应消息及统一异常处理
平时开发过程中,无可避免我们需要处理各类异常,所以这里我们在公共模块中自定义统一异常,Spring Boot 提供 @RestControllerAdvice 注解统一异常处理,我们在GitEgg ...
- RabbitMQ的一些理解和笔记
在这篇博客中,简单记录一下 rabbitmq 服务器中一些基本的概念. Connection: connection 为 TCP连接,是我们的应用程序和RabbitMQ服务器真正发送和接收数据的地方. ...
- 写一段java程序来执行linux命令
摘要 在日常开发中,程序员需要经常查询服务器日志来排查问题和调试程序.如果是本地调试还好,但项目一旦发布到服务器上,每次查日志就很麻烦,而且日志量巨大,有时我们无法找到我们需要的信息.经常需要借助第三 ...