Java中的数据结构
Java中的数据结构若不提到Jdk版本,本文中的源码都是基于jdk8版本分析的 注:有关同步集合(如Vector、ConcurrentHashMap、CopyOnWriteArrayList等)请移步博客 数组集合类,是Collection接口的子类,有序的Collection实现,包含ArrayList、LinkedList、Vector,其中Vector是线程安全的ArrayList,LinkedList是底层基于双向链表实现的List ArrayList的默认大小为10,扩容操作: 也就是1.5倍 不重复集合类,不能包含重复的元素,是Collection接口的子类,包含HashSet、LinkedHashSet、TreeSet,其实都是基于Map类的实现,所以详细了解请参阅Map类

2019-07-12鱼鱼
算法:Trie(前缀树、字典树)
算法:Trie(前缀树、字典树)前缀树(Trie,又称字典树)是一种功能倾向性很强的数据结构,通过对词汇的前缀做数结构,很容易实现查询、前缀词推荐系统,例如,我们将如下多个单词放入树结构中: [apple,bat,bee,cat,cap,car],最终生成的前缀树结构为 通过深度递归,我们很容易用较小的时间复杂度判断出符合前缀的单词在不在 假设Trie的字符集范围是固定的,并且范围不大,例如是上面的纯英文字符,假设忽略大小写总共为26个,可以选择使用桶结构进行存储,即每一个Node都是一个长度为26的bucket数组 这样看来,Trie的结构并不复杂,只通过循环不断提高深度进行遍历即可 假定字符集的范围是未知的,或者范围很大(比如中文汉字),就要放弃使用bucket结构,而是通过一个Map维护,这里使用树结构TreeMap,key为相应节点的字符

2021-01-19鱼鱼
用Quartz 写定时任务
用Quartz 写定时任务Quartz是OpenSymphony开源组织在Job scheduling领域的一个开源项目,是一款清新友好的任务调度框架 Quartz两大基本功能是job和SimpleTrigger(作业和触发器) 核心的是Scheduler类 有以下几个相关类: Scheduler:定时任务调度; Job:任务类需要实现的接口; JobDetail:Job的实例,被Scheduler执行的是JobDetail,而不是Job; Trigger:触发Job的执行; JobBuilder:定义和创建JobDetail实例的接口; TriggerBuilder:定义和创建Trigger实例的接口;

2019-06-18鱼鱼
对多线程的执行效率探究——合理的任务并发拆分
对多线程的执行效率探究——合理的任务并发拆分通常,我们选择多线程执行任务有两个理由,一是复杂任务采用多线程处理能够在发生并发时让用户减少等待也能防止阻塞,一是充分利用空闲时间,提高任务处理的效率,就后者而言,此处探讨不考虑客户端并发是否有必要把一个任务拆分成多线程来处理 为了探究多线程的效率问题,我做了一个实验,将不同种类的任务分别用单线程和多线程执行,同时也试验了不同种类的锁机制 测试基于Java 8的版本,希望看到总结可以直接点击到文末 开启五个线程执行任务,设定了足够次数的循环输出,输出的数字和当前线程,利用System.currentTimeMillis()统计任务用时 (代码略)以下是相同任务在不同环境下执行多次的平均执行时间

2019-12-09鱼鱼
浅谈代理-动态代理
浅谈代理-动态代理我们可以很轻松的实现一个简单的代理 实现静态代理是个很简单的事情,最基础的代理只需要定义一个接口(虽然不是必要,但这显然才是标准的设计)、一个被代理类和一个代理类,例如: 定义一个接口: 一个实现类: 和一个代理类: 实际使用时,我们是去调用HelloWorldProxy的方法,其将作为HelloWorld的代理实现 此种方式直接实现的代理太过于死板,因为每一种代理行为都要制定一个代理类,我们熟知的很多基于代理的实现(譬如AOP、事务)显然不可能用静态代理的方式针对每一处类切点都覆写一个代理类,这种时候就需要动态代理 我们所熟知的相当多的框架均基于动态代理开发,JDK本身基于反射(java.lang.reflect)提供了动态代理,我们只需定义代理的行为,而对于代理类的范围并不是固定值
![浅谈代理-动态代理]()
2020-10-13鱼鱼
待办事宜
待办事宜2018-10-18 解决XSS攻击问题(v-html) 针对缺省有所设置(blog:page等) 添加新增按钮 添加置顶 解决日志编辑首行出现空格 开发射线:一个匿名交流板 留言 联系方式 可回复 筑楼 时限性 超时关闭 匿名 默认匿名 字典: 可标注,添加富文本新组件字典(视情况添加 工作量难以预估 可考量在全网) 字典包括 可见性(待定),条目,解释,相关词条 必须可编辑 添加不同风格 参照http://www.unconstraint.cn/,github两种风格可切换 流动 简约 重金属 使用图床存储较大的图片(RECOMMEND:使用新浪微博)
![待办事宜]()
2019-03-24鱼鱼
算法:深度优先搜索(DFS)
算法:深度优先搜索(DFS)在算法:广度优先搜索(BFS)(最短路径)中,我们提到了按照广度优先遍历的搜索方式,使用队列作为常规的搜索方式,与之相对应的为深度优先搜索(DFS) 如果说BFS对应着树结构的前中后序遍历 但是DFS相对解法较为多元一些,有些时候不得不使用递归进行求解 同时,有很多求解只是进行图的遍历,不关心是广度还是深度优先,其解都是相同的 在这里我们暂且不讨论的基于栈而是侧重基于递归的遍历实现 对于二叉树,最常见的遍历方式有前序(又称 先序)遍历、中序遍历、后序遍历、层次遍历 前中后序只为取得的值先后顺序不同,即递归有先后 依赖栈实现的的深度优先是前序遍历 以下是一个二叉树的前序遍历代码实现:
![算法:深度优先搜索(DFS)]()
2020-06-27鱼鱼
tips
tips一些小tip: 向上转型,失去特征 定义相同对象,重写hash和(不是或)equal Vue.nextTick() 回调函数:在Vue(重新)渲染页面之后调用 vue绑定样式,我们会发现background-color 不能直接绑定 需写为backgroundColor 因为js中不允许出现‘-’ 存库之前,mysql会把换行符什么的过滤掉,使得出入不一致(应用场景:textarea存)解决:this.value.replace(/\n|\r\n/g,"
") linux下的mysql的表名是区分大小写的! 实现线程接口 Runnable 注解注入失败 注解注入失败 Linux下缺少部分字体,使用drawString会出问题(二维码模块),解决手段:从windows引入字体,因为不是什么主流问题所以就简单写一下,如果再碰到相关问题在详细的讲述一下
![tips]()
2019-05-08鱼鱼
Redis原理-源码解析:数据结构3 sorted set(zset))
Redis原理-源码解析:数据结构3 sorted set(zset))Redis的set数据结构在此不多讲,同Java中原理一样,set也可以理解为是hash剥离了value的数据结构,即同为dic 但是zset(有序集合)其实在底层原理上完全不同于set 所有原理实现基于Redis版本6.0.9 先看一下基本的指令实现,着重注意中文注解的地方 t_zset.c 可以看出zset的数据结构不是固定的,在其元素数或是元素的字符串过长时,其结构为zset;否则使用ziplist数据结构(像hash一样为了节省空间),二者的创建方法如下: ziplist的代码和原理可以参考我的博客Redis原理-源码解析:数据结构2 list-鱼鱼的Java小站,就是一个节省内存的压缩的链表结构

2021-02-28鱼鱼
多线程应用提高(IV) 线程安全的集合类
多线程应用提高(IV) 线程安全的集合类在Java中的数据结构一篇中,列举了Java中一些常见的集合,此文主要梳理线程安全的相关集合 我们知道,当一个实例对象只能被一个线程访问时(线程私有),无论如何都不会有线程安全的问题,但在多线程的情境下,多个线程操作同一个对象时,可能会出现更新丢失、读写数据不同步、计数击穿等现象,此时这种操作就是非线程安全的 相应地,线程安全的集合有这样的特点:在多个线程操作同一集合时,能保证每一步操作都是安全的,与串行执行的结果一致,不会出现数据不同步等预料之外的问题 可以先看这个小例子Java-lab/ListT.java at master · fishstormX/Java-lab,我在里面解释了
![多线程应用提高(IV) 线程安全的集合类]()
2019-07-13鱼鱼
算法:动态规划解法及例题
算法:动态规划解法及例题经历过很多算法题,其中最常见的解题方法便是动态规划 动态规划(dynamic programming,即DP),是一种常见的求解最优解的方案,他通过将复杂的问题拆分为单阶段的小问题求解,核心思想是递推,通过简单基础的解一步步接近最优解 对于一个算法问题,总有一个相对令人满意的解,但却不一定是我们想要的最优解,譬如在解决动态规划中最经典的背包问题时,有些人首先想到简单省心的贪心算法,取价值最高或是性价比最高的物品组合,这种方案得到的很有可能是最优解,但贪心的算法并不适用于动态规划领域,若是物品中恰好有能将背包塞得很满的组合,而采用贪心策略却浪费了很多背包空间 其实贪心策略本身更多也是一种“相对最优”的解决方案,而很少是真正的最优,这一点请务必斟酌

2020-03-11鱼鱼
IO多路复用模型:select、poll、epoll对比
IO多路复用模型:select、poll、epoll对比我们平时提到的I/O几乎都是同步 阻塞模型,譬如网络请求的socket IO,在数据返回前,相应的线程或是进程将会一直 阻塞直到数据返回,比较直接的处理便是针对IO流一对一的监听,但在IO返回前,相应的系统资源会平白无故的浪费,这种处理方式会大大降低服务器的吞吐 如果我们用很少的线程来监听这些IO,就能实现对系统资源的更好利用,在相应的socket有数据返回时才去读取数据 这种方式被称作IO多路复用,在Linux系统中,实现IO多路复用的方式(从古老到新)有select、poll和epoll 现在很多中间件都使用epoll IO多路复用模型才因此有着很高的性能和吞吐 此处简单描述三种方式的实现和区别

2020-08-11鱼鱼