在网上看了很多资料,找到一篇讲哈希表的,感觉非常不错,推荐直接去看原文,散列表的基本原理与实现
下面内容是我的一些为加深记忆而复制的笔记,并无新意。
散列表的工作过程:
- 首先我们使用散列函数将给定键转化为一个“数组的索引”,理想情况下,不同的key会被转为不同的索引,但在实际应用中我们会遇到不同的键转为相同的索引的情况,这种情况叫做碰撞。解决碰撞的方法我们后面会具体介绍。
- 得到了索引后,我们就可以像访问数组一样,通过这个索引访问到相应的键值对
在网上看了很多资料,找到一篇讲哈希表的,感觉非常不错,推荐直接去看原文,散列表的基本原理与实现
下面内容是我的一些为加深记忆而复制的笔记,并无新意。
散列表的工作过程:
关于一致性哈希算法的介绍,网上挺多的,图文并茂,易懂详细,例如:一致性哈希算法与Java实现
平时要操作线上数据库,只能通过跳板机来连接到生产数据库,然后执行一些sql. 例如,运营同学会筛选出一批活动id,我们需要批量修改下这些id对应的数据过期时间信息,通常我们只需要连接到数据库执行类似update t_activity set ent_time=1234554 where activit_id in (xx,xxx,xx)
的sql就行。
但有时候,运营同学给的id文件中,有几百,上千个。如果我们手动把这些id,用逗号隔开,一个一个拼接到sql中,然后复制这条sql,去执行。就会非常麻烦。这时候下面简单脚步就可以快速搞定。
shell 中读取文件的每一行,有很多实现方式,但fro,While
循环的方式是最容易理解的,接近平时编程语言方式。
我们知道,JVM运行时数据区域中有一个线程私有的区域Program Counter Register,姑且翻译为程序计数器。 当然也有翻译为 PC寄存器的。以下简称PCR. 我们知道在计算机的CPU中有两个专有的寄存器
在JVM中,这两个专有寄存器功能应该是融合的(没考证,推测的,但不影响理解其功能)
今天遇到个坑,因为凌晨要执行个脚本,把一些数据从一个表清洗到另一个表。结果写好脚本,线下服务器测试crontab定时任务的时候,到时间死活就是不执行。后来找同事看了下,才发现
Linux 下的crond服务,所用的cron表达式,只能精确到分,而通常项目中,例如spring,quartz 是可以精确到秒的。
结果我复制的项目中平时运行好好的的cron表达式,自然无法定时执行。
cron有两个配置文件,一个是全局配置文件(/etc/crontab),是针对系统任务的;一组是crontab命令生成的配置文件(/var/spool/cron/用户名 下的文件),是针对某个用户的. 通常都用/var/spool/cron下的。
这几天在对自己业务组的十几个模块进行日志升级,从log4j1 升级到log4j2. 在实施的过程中遇到各种各样的问题,其中有个问题特别突出,导致好几个项目没法升级。
首先说下背景,我们这些模块只是集团一个小业务线中的子模块,除业务部分外代码需要自己编码外,项目中其他部分代码从框架,数据库,公共组件都是使用集团统一所谓的自研框架,例如有个叫XYRedis组件,XY
是公司名字,其只不过是把redis的大部分代码copy过来,连包名都不改,套了个maven壳子。经常出一些莫名其妙的问题,一看日志,不对啊,jedis官方怎么会犯这样低级错误。总之,东施效颦一般。
就说这次日志升级中最令人发指的部分,这些公共组件,有好些个居然使用的日志框架是log4j 而不是 SLF4J, 导致我们项目没法从log4j1 升级到log4j2 (两者配置文件格式不兼容),一启动项目就包错,找不到合法的日志配置文件,一查原来是依赖的公共组件要用到旧的配置文件,奔溃。
我们知道HotSpot虚拟机把堆空间(内存上可以是不连续的)分成不同区域,来进行所谓分代收集。 其中又根据来自IBM一些数据研究结果,把一些朝生夕死的短命鬼划分到年轻代,其他一些老不死的放到老年代。 当年轻代存不下新分配对象时候,就会触发所谓的Minor GC,进而引发老年代和新生代之间的分配担保机制。
关于分配担保机制的详细过程,网上充栋,这里就不说了,但更有意思是,这种机制不需要可以吗?使用了它又有什么意义?实际工作场景中有没有可以参考的。
分配担保机制中,无论是新生代所有对象总和还是历次晋升到老年代的平均大小的经验值,在进行比较时候都会和老年代最大连续空间进行比较。 难道不连续只要凑起来够就不行了?毕竟老年代还是**标记-清理-(压缩)**算法。