算法：Trie(前缀树、字典树）

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

JVM源码解析(2) ContextClassLoader与ClassUtil.forName()方法浅析

JVM源码解析(2) ContextClassLoader与ClassUtil.forName()方法浅析在Spring获取Context的源代码中，我们看到了对ClassUtil的方法调用，通过给定ClassName和ClassLoader进行Class的加载： ClassUtil.forName是仅供于Spring内部使用的获取Class对象的方法，来看一下源码： 首先 对于缓存的Class一块，在类的静态块中就能看出其逻辑： 在上面的resolvePrimitiveClassName方法中，先对长度做了一个判断，因为较长的packagename会影响执行的性能： 最终加载Class依旧是通过ClassLoader的，先来看一下获取ClassLoader的方法实现： 此处优先使用了ContextClassLoader作为 类加载器而非默认的AppClassLoader，在JVM源码解析 从 Launcher类浅谈ClassLoader中，提到了关于 类加载器的相关知识，使用ContextClassLoader是为了弥补双亲委派加载机制的对于自定义 类加载器的缺憾：那些自定义的 类加载器并没有机会上场，在使用了AppClassLoader后我们的自定义ClassLoader所加载的Class是无法被加载进去的，使用ContextClassLoader，我们可以在定义线程时，通过Thread的init方法(子线程调用，私有方法)或是setContextClassLoader直接指定使用自定义的ClassLoader
2020-08-16鱼鱼

Spring MVC源码和设计思想2 HandlerMapping

Spring MVC源码和设计思想2 HandlerMapping系列传送门Spring MVC源码和设计思想1 DispatcherServlet-鱼鱼的博客 此篇篇幅很长，且慢慢道来 在之前一篇中，DispatchServlet的doDispatch()方法中有这么几行： 其中getHandler方法： handlerMappings是一个初始化过的List，通过它获取HandlerExecutionChain HandlerExecutionChain存储了一个Object（其实就是HandleAdapter）和一个拦截器(HandlerInterceptor)数组，在doDispatch方法中执行了applyPreHandle和applyPostHandle方法，方法就是分别迭代调用了拦截器数组的postHandle和preHandle，同样地，发生异常时的triggerAfterCompletion也映射到了afterCompletion方法
2019-06-12鱼鱼

ES快速入门(2)——Tokenizer、Reindex

ES快速入门(2)——Tokenizer、Reindex本篇介绍es提供的几种分词分析器和常用的开源分词分析器 es默认的分词器，中规中矩的按照 Unicode Standard Annex #29分词，一般的小写符号会忽略，对于中文等字符会逐字分割，参数max_token_length表示最大的字符长度，再切分后会继续按此切分 譬如： 会分词为： 一个无视语义，按照字符尽量收集全索引的分词方式，会前后叠加的按符号位分词，参数： 会分词为： nGram的分词很全面，但如此夸张的方式用不好会导致索引doc过大，同时使查询效率偏低 分词规则很简单，无其余规则的按空格分词： 会分词为： 在standard的基础上能够有效拆分出邮箱和url地址的格式，同样有max_token_length这一参数：
2020-09-05鱼鱼

DDD领域下的架构模式——CQRS架构

DDD领域下的架构模式——CQRS架构//TODO
2021-06-24鱼鱼

有关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中,可以使用：
2019-03-08鱼鱼

Elasticsearch 入门

Elasticsearch 入门(注：本篇文章基于Elasticsearch7.7.0版本，由于版本的差异性造成的内容不一致我会尽量在文中标出，但是) Elasticsearch是基于Lucene扩展的全文搜索引擎，当我们有对大数据量的处理和搜索时，全文搜索引擎是最佳的选择，同时他提供了高扩展性、高可用性、RestFul风格的API和友好的分布式部署配置，在此我们不予详述 我们日常使用的数据库索引是数据库一种编排数据（逻辑上）从而加快查询的手段，我们暂且将这种索引方式称为正排索引，他通过对待搜索字符寻址从而找到对应的数据 但是这种索引方式对于模糊匹配会出现"断档"现象（模糊符号后的片段无法走索引查找），并且对于海量数据无论在存储上还是在查找上都略显吃力，于是在Elasticsearch中引入了倒排索引来加快查询速度
2020-03-06鱼鱼

算法：动态规划解法及例题

算法：动态规划解法及例题经历过很多算法题，其中最常见的解题方法便是动态规划 动态规划（dynamic programming,即DP)，是一种常见的求解最优解的方案，他通过将复杂的问题拆分为单阶段的小问题求解，核心思想是递推，通过简单基础的解一步步接近最优解 对于一个算法问题，总有一个相对令人满意的解，但却不一定是我们想要的最优解，譬如在解决动态规划中最经典的背包问题时，有些人首先想到简单省心的贪心算法，取价值最高或是性价比最高的物品组合，这种方案得到的很有可能是最优解，但贪心的算法并不适用于动态规划领域，若是物品中恰好有能将背包塞得很满的组合，而采用贪心策略却浪费了很多背包空间 其实贪心策略本身更多也是一种“相对最优”的解决方案，而很少是真正的最优，这一点请务必斟酌
2020-03-11鱼鱼

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

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

浅谈锁机制、主流锁设计方案

浅谈锁机制、主流锁设计方案本文旨在探讨通用的锁机制实现逻辑，以Java中常见的锁实现为例 本文提到的锁，是指通过限制并发/并行访问所添加的安全措施，本质上是通过限制线程/进程同时更改数据或是读取数据与写入数据产生时序差从而造成数据问题 锁机制中，有一些常见特性： 可重入性 指同一线程/进程携带相同的标识可以反复多次加锁，每次加锁和释放锁对应的重入次数+1/-1； 读写锁/独享共享 是锁的不同运作模式，分为读写锁，读锁与写锁、写锁与写锁是互斥的，但多个线程/进程可以同时对一个逻辑添加读锁，独享共享是另一种叫法 公平性 锁分为 公平锁和非 公平锁， 公平锁指锁释放和获取的顺序严格按照索取的顺序，非 公平锁则是等待锁的对象共同进行锁释放机会的争抢
2024-10-15鱼鱼

MySQL tips

MySQL tips一些日常接触到的MySQL优化tips，比较散乱 假设有一个用户表，对于一句很简单的查询语句： 假设name与age字段均有单列索引，容易想到的是，MySQL应该会分别走两次索引，并将其结合起来，EXPLAIN也是如此，大多数时候MySQL会进行优化，我们可能会看到EXPLAIN的结果中有Using union或Using soft union，这是MySQL针对OR做了隐性的优化，但当SQL复杂或数据极端情况下，这一语句极容易变成全表扫描，偶尔使用联合索引可能解决问题，更多情况则是MySQL“昏了头”，即使OR条件均涉及数据条数不多，依旧没能在查询语句中使用索引，此时应调整为UNION语句(可以权衡一下重复及顺序是否有影响，可以使用更快的UNION ALL)：
2021-01-13鱼鱼

Netty

NettyNIO相比IO有诸多利处，但平常开发中若是直接使用原生NIO进行业务开发是很不可取的，否则将面临臃肿而晦涩难懂的代码 所以日常开发中我们会时常使用封装了NIO操作代码的Netty来实现NIO操作 Netty是一个异步事件驱动的网络应用框架，用于快速开发可维护的高性能服务器和客户端
2019-05-11鱼鱼

网站地图

首页 博客 {{screen}} 第 {{page}} 页

{{blog.title}}

{{blog.content}}

{{blog.createDate}} ◔ {{blog.timeline}} {{blog.author}} {{tag}}

{{blog.likeCount}}{{blog.commentCount}}

分类下暂时没有文章哦！

主题分类

源码解析

造个轮子吧

多线程应用提高

问题探究

来做几道算法题

微服务架构实战

QuickStart

电子出版物

Java排坑指南

做点有趣的！

瞧瞧看看MySQL

{{taggroup.label}} 

{{tag.value}}