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类
Java中的数据结构2019-07-12鱼鱼

ES快速入门(I)——分析分词器

ES快速入门(I)——分析分词器本文旨在快速入门Elasticsearch的分词,包括分词分析器的创建和介绍对比等,请确保在阅读前已经搭建好完备的集群 文章基于es7.0+,与稍旧版本的主要区别是没有type 在讨论分词前,我们先看一下es整体创建倒排的分词过程: 我们常说的分词器指的其实是“分析器”analyzer,es将以上常用的逻辑封装起来成为analyzer,但是语义上的分词器是指上面的tokenizer 经过了三层处理后拿到了terms数组建立最终的倒排索引: character filter:一般不会用到这个filter,是在分词前对原有的文档字段内容做转换,例如去除html的标签提取出正文内容,按正则清除和替换某些内容,你可以指定及自定义0个到多个character filter,他们将共同存在,一个文本流在经过character filter处理后,依然是文本流;
ES快速入门(I)——分析分词器2020-09-01鱼鱼

1
空2025-09-05鱼鱼

算法:深度优先搜索(DFS)

算法:深度优先搜索(DFS)在算法:广度优先搜索(BFS)(最短路径)中,我们提到了按照广度优先遍历的搜索方式,使用队列作为常规的搜索方式,与之相对应的为深度优先搜索(DFS) 如果说BFS对应着树结构的前中后序遍历 但是DFS相对解法较为多元一些,有些时候不得不使用递归进行求解 同时,有很多求解只是进行图的遍历,不关心是广度还是深度优先,其解都是相同的 在这里我们暂且不讨论的基于栈而是侧重基于递归的遍历实现 对于二叉树,最常见的遍历方式有前序(又称 先序)遍历、中序遍历、后序遍历、层次遍历 前中后序只为取得的值先后顺序不同,即递归有先后 依赖栈实现的的深度优先是前序遍历 以下是一个二叉树的前序遍历代码实现:
算法:深度优先搜索(DFS)2020-06-27鱼鱼

造轮子1 注解管理

造轮子1 注解管理使用public @interface xxx{}可以自定义一个注解,在注解上面定义的注解叫做元注解 以下代码取自开源API文档生成项目Swagger: 在注解中也可以使用注解,我们称这些注解为元注解,上面代码中使用了一些比较常见的元注解 @Target({ElementType.TYPE})用于定义注解的使用范围,常见的包含 TYPE:类、接口、枚举 FIELD:字段声明 METHOD:方法声明 PARAMTER:参数声明 CONSTRUACTOR:构造函数声明 LOCAL_VARIABLE:局部变量声明 ANNOTATION_TYPE:其他注解声明 PACKAGE:包声明(代码中的第一行 声明package的时候)
造轮子1 注解管理2019-05-25鱼鱼

扫盲——加密那些事

扫盲——加密那些事扫盲加密解密算法 日常开发中我们经常接触MD5算法,以此进行简单的文件完整性校验或者是后台密码验证,MD5是最常见也是最简单快捷的散列算法,常用于参数或文件完整性校验,譬如网络请求发起方与接收方分别对参数做MD5编码,一旦不一致便判断请求被篡改从而拒绝该请求,从而保证信息安全,编码后的字符串是编码前文本的一个简要梗概,因此它也被称作是信息摘要算法 这个算法的特点就是不可逆,只用于信息准确性和防篡改的校验,当然,MD5作为老牌的散列算法,很多经典的编码已经可以被反向解码出来(依靠正向的暴力穷举)以及被碰撞模仿(王小云院士团队的"破解"能够根据MD5编码后串码模拟原始消息,即使它可能与原信息不同),类似的还有SHA1,因此衍生了SHA224、SHA256、SHA512等更多安全的散列算法
扫盲——加密那些事2021-05-14鱼鱼

有关Session的碎碎念-ban掉cookie之后

有关Session的碎碎念-ban掉cookie之后java web中, 用session来表示用户浏览器(客户端)与服务器建立的一次会话 通常用sessionId来标记一个session,在Java中,有很简单的方式直接获取sessionId; 但是sessionId并不是session的特性,实际上,sessionId是在客户端首次创建会话时将生成的sessionId存入cookie中,在之后的访问中直接读取这个id值 当客户端禁止了cookie行为后,SessionId在每次刷新页面时都会更新,利用id来表示会话也成为了妄想,此篇文章意在说明,如何操作能使SessionId能够独立于cookie使用 这种操作其实在shiro中已经被应用了,当我们进入登录页面中,url后会出现";jssionid=xxxxxx",将sessionid显示的标注在url中,可以使用:
有关Session的碎碎念-ban掉cookie之后2019-03-08鱼鱼

IO多路复用模型:select、poll、epoll对比

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

杂记:Spring与Springboot的本地化配置

杂记:Spring与Springboot的本地化配置利用这篇文章巩固一下Spring框架的基础,因为发现接触到的各种Spring的项目配置杂七杂八,从xml到注解,从properties到json到yaml,他们各有千秋,没有哪一种方式可以绝对取代另一种配置,所以在这里统一介绍一下各种配置方式的内容和利弊,以便随时查看 这并不是一篇Spring框架领域的教程,只是一种技术的补足或是一种投机取巧的学习手段 原始的Spring是采用纯xml进行配置的,我从github上找了一个规范经典的SSM项目,以下是一些常用的配置,从这里就可以看出xml的基本格式: ApplicationContext-test.xml jdbc.properties
杂记:Spring与Springboot的本地化配置2020-03-01鱼鱼

使用RPC与Restful接口调用服务

使用RPC与Restful接口调用服务在SOA和微服务架构中,远程通信是无法避免的,最常用的远程通信有两种方式: restful的接口,使用Http通信 使用dubbo或是Spring Cloud组件进行 RPC协议远程调用,可选地使用socket通信 不同的人对 RPC调用会有不同的看法,甚至对rpc本身的理解都不甚相同,但我认为 RPC有两种倾向: 一为语义化的 RPC 没有统一的请求规范,数据格式在开发人员中很难达成一致,在使用传统Http调用时,交互的双方需要约定一份“API文档”以保证数据格式的唯一性,这样API格式本身就成为了一道大墙,耽误研发双方的时间 但如果服务间采用语义化 RPC进行交互,双方可能并不需要一份文档,只要一份约定好的代码,并以此作为双方的依赖,在请求时也仅仅是直接调用方法本身,如此强的语义性怎能让人不爱
使用RPC与Restful接口调用服务2021-01-13鱼鱼

PyCharm与python快速开发

PyCharm与python快速开发Python语言作为“胶水语言”,简单易学,开发周期快,功能和扩展性强大,类库丰富 只依赖一门Java并不适用于所有情况,譬如快速开发一次性脚本(修复数据),通过使用Python效率更高,本篇文章旨在介绍本人快速入门Python的一些tips 注意,一些Python的基本语法在此不予介绍,推荐前往廖雪峰的博客查看,博客基于Python3.8版本 关于编译器等配置内容参考PyCharm帮助文档 从Python官网下载Python并安装,配置环境变量,安装PyCharm(这里 我们使用它作为IDE),这里略过 pip是python的包管理与安装工具,当你安装python后,pip也会随之被安装
PyCharm与python快速开发2021-01-16鱼鱼

数据库的瓶颈问题解决(主从分离)与多数据源切换

数据库的瓶颈问题解决(主从分离)与多数据源切换业务中,数据库的设计是极为重要的一环,在高并发的业务中,我们可以采用集群部署来缓解请求和逻辑处理的压力,但是在数据库的层面却不行,Oracle、Mysql等数据库的吞吐量很高,但是依旧有阈值,我们不能奢求单库能解决所有的问题,假设遇到了数据库的瓶颈问题,我们可以采用怎样的手段呢 想要数据库达到瓶颈(SQL执行效率明显变慢),其实是很困难的,我们在程序的设计中基本都会使用到数据库连接池控制数据连接,但当业务量提升之后,连接池若是经常达到饱和便容易产生阻塞,我们不得不开放更多的连接数,随之而来的便是数据库承载了更多的并发,解决问题的主要方式有三: 更细的划分业务逻辑,将高频业务表单独分离开来,并通过定期清理的方式减小查询的执行时间,将不同的数据库请求分发到不同服务器的不同库,可以一定程度下解决上文所述的问题,但是应以数据库的设计性为前提,绝对不能牺牲原有设计合理的数据结构将其进行拆分,得不偿失
数据库的瓶颈问题解决(主从分离)与多数据源切换2019-08-29鱼鱼
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}