设备端受理刷卡，系统会下发几万条黑名单开卡号，设备刷卡的时候要能在几毫秒判断出是否是黑名单卡号。
已有的.so库文件通过把卡号哈希计算一个数值然后映射到文件bit位置。 通过bit位0和1来判断是否存在黑名单。
设备端是c开发，没有数据库，且几万条下载经常出错，处理又耗时。
现在的需求：想在系统端用java直接把黑名单生成哈希文件，下发给设备
我自己试过把19位卡号hash ，然后取3个字节算10进制值，然后用200 0000 做模值取余得到文件bit位偏移，但是发现实际很大概率会出现碰撞。
，有几个问题
19位数字是9个字节存储的？
为啥设备自己生成哈希可以正常运行 java 的方式碰撞变大了。是用的方式不一样？
可以考虑一下 分页+hash
你的java哈西算法贴下，生成的多少位?可能是你hash算法碰撞率就很高，最笨最有效的方式，要到C的代码，原样翻译，别自己想算法或者用java自带了
先卡号排序，然后可以折半查找，时间复杂度是log级
按data为编号值的每个位数，建深度为20的树，每次查询递归的次数永远小于等于19，且方便插入新名单。
可以考虑各种不同的方法：
使用设备端现有的哈希计算代码，用java代码写一个相同的
下载黑名单列表 改为 下载增量黑名单列表
空闲时周期性下载黑名单列表，不影响用户使用
设备端只缓存最后几十几百次黑卡，在缓存内的直接判断出黑卡，不在缓存内的服务端判断出黑卡，设备端再缓存下次就能判断