Java排坑指南(I)jmap jstack jstat等的使用
Java排坑指南(I)jmap jstack jstat等的使用运用一些Java自带的可执行jar可以从内存的角度更轻松的排除项目中的问题，我们可能会遇到一些不常见却相对很致命的问题，例如： 某些web项目CPU跑到了100%并且飙高不下（一般来说，web应用都为IO密集应用，不太可能出现cpu高占用的情况） 项目中线程出现阻滞、阻塞（网络请求响应速度明显变慢，甚至因为死锁彻底出现阻塞等） 极可能由内存泄漏引发的不明原因的 OOM（没有预兆的或是基础逻辑问题的内存溢出） 当以上问题发生时，通过代码或是日志其实很难定位到原因所在，因为这一般是基于环境或资源导致的全局性问题，通常很难定位，这时可以通过使用Java自带的性能调优jar包更便捷的定位问题（如果没有配置环境变量，可以在jdk的bin目录下找到他们的jar包）
2020-11-28鱼鱼
多线程应用提高(IV) 线程安全的集合类
多线程应用提高(IV) 线程安全的集合类在Java中的数据结构一篇中，列举了Java中一些常见的集合，此文主要梳理线程安全的相关集合 我们知道，当一个实例对象只能被一个线程访问时（线程私有），无论如何都不会有线程安全的问题，但在多线程的情境下，多个线程操作同一个对象时，可能会出现更新丢失、读写数据不同步、计数击穿等现象，此时这种操作就是非线程安全的 相应地，线程安全的集合有这样的特点：在多个线程操作同一集合时，能保证每一步操作都是安全的，与串行执行的结果一致，不会出现数据不同步等预料之外的问题 可以先看这个小例子Java-lab/ListT.java at master · fishstormX/Java-lab，我在里面解释了
![多线程应用提高(IV) 线程安全的集合类]()
2019-07-13鱼鱼
ELK实战(Ⅰ) 基于ELK整合分布式业务日志
ELK实战(Ⅰ) 基于ELK整合分布式业务日志大多情况下，我们可能都习惯了使用linux指令查看日志，很多时候一句简简单单的tail、grep能定位绝大多数问题 但是面临复杂的目录结构和分布式系统产生的“分布式日志文件”，如果还要我们一个一个去查日志，就会耗费很多没必要的时间 可以利用ELK这套组件快速搭建一个日志系统 注意此文仅针对可能很多情况下格式不确定的业务日志，对于某些组件日志我们有更好的可视化实践方式，可以参考此系列的其他文章 对于一个日志系统，我们要确认我们的诉求，在不同的场景下采用不同的收集方式： 是否是分布式系统需要合并多个节点的日志 如果需要，则需要用分布式组件收集并合并日志，这也是一个日志系统最基本的要求；
2020-03-14鱼鱼
Redis高级特性：事务和pipelined以及在RedisTemplate中的应用
Redis高级特性：事务和pipelined以及在RedisTemplate中的应用Redis Pipelined是由Client提供的(是防止client端 阻塞的操作)一种请求redis的方式 Redis本身具有很高的吞吐量，因此性能最大的考察便是网络状况，如果应用到redis的网络状况不好，每次请求都将会出现轻微的 阻塞和延迟，这种延迟对于批量请求是很可怕的，譬如要进行数千次数据插入，或是批量获取数据时，我们就需要用到Pipelined Pipelined可以将多个请求无 阻塞的发出并按顺序将请求结果“打包”返回，这有点类似于并发请求，可以有效地利用等待结果的 阻塞时间 注意，Pipelined并不能保证原子性，即pipelined执行的内容可能会被其他客户端或是线程的指令"插队"，若想要原子性操作，需要使用事务
![Redis高级特性：事务和pipelined以及在RedisTemplate中的应用]()
2020-06-21鱼鱼
多线程应用提高(I) 多线程常见问题、常用方法和关键字
多线程应用提高(I) 多线程常见问题、常用方法和关键字我们一般熟识的创建多线程方式即为继承Thread类或是实现Runnable接口，重写run()方法，还有创建线程池实现 手动定义一个线程任务（作为内部类）的方法现在已经不被提倡，所以遇到可能存在并发的复杂任务时，一般采用线程池来实现 一些设计并发常用并且容易被混淆的方法们： static sleep() : Thread类的静态方法，阻塞当前正在线程，不释放锁； wait() : 当前线程暂停，并释放锁且暂时无法重新获得锁，必须绑定当前对象内容锁（如使用Synchronized的同步块），知道其他线程调用notify()/notifyAll()才有机会获得锁继续执行； yield() : 当前线程暂停，此时时间片分配给其他线程，但是不会分配给优先级更低的线程；
![多线程应用提高(I) 多线程常见问题、常用方法和关键字]()
2019-12-07鱼鱼
Redis原理-源码解析：数据结构3 hash
Redis原理-源码解析：数据结构3 hash 所有原理实现基于Redis版本6.0.9 hash在Redis中可以认为是套了一层的string，当然，对hash来说没有数字类型 让我们依旧通过基本命令看看hash的基本数据结构实现 在set方法中我们看到了hash的初始创建过程，一个hash最开始是zipist 想要了解ziplist可以看Redis原理-源码解析：数据结构2 list ，是为节省内存而生的链表格式 所以其实在使用ziplist时其查询的时间复杂度不是遵循hash的近似O(1)，而是O(n)，但是在数据量不大时，这种性能的损失微乎其微，并且能预见到大多数使用hash的场景都不会存储过多的字段 所以优先使用了更节省内存空间的ziplist
2020-11-29鱼鱼
关于多数据源的那些事儿（萌新向）
关于多数据源的那些事儿（萌新向）在日常的JAVA后端开发中多数据源的应用场景并不少见，但对于刚刚接触springboot或是刚刚接触工程化开发的萌新来说却仿佛是一座不可逾越的高山，因为新手常常会局限于某些“固定的”项目配置，不知道如何配置？从哪里开始配置？以及什么能改什么不能改 这种现象在用惯了springboot便捷开发的老手中也很常见，众所周知，相比于spring的springboot简化了很多工程前置配置，虽然增加了工作效率却也使得开发人员失去了了解基础配置的机会 综上，本文主要讲解如何在springboot环境中，以一种最简单的、即起即用的、不依赖中间件和数据库切片的方式配置单一项目的多数据源 限于笔者能力有限，经验尚浅，若有描述不当之处，敬请批评指正
2019-06-28Agostino
JVM与GC
JVM与GCJMM，长下面这个样子： 其中，堆和栈区自然不做介绍了，主要介绍： 程序计数器：线程私有的，记录正在执行的字节码地址，换言之，它告诉我们某线程执行到了那里，分支、循环等也会依赖这个来执行，这一区域不会发生OOM问题 栈：就是正常所指的栈，每个方法被执行的时候都会同时创建一个栈帧（Stack Frame ）用于存储局部变量表、操作栈、动态链接、方法出口等信息 每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程，这一区域会发生StackOverflow问题 堆：就是正常所指的堆，这里是GC的主要区域 方法区：线程私有的，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据，运行时常量池也包含在里面
2019-03-28鱼鱼
Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听
Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听查看源码的顺序就见仁见智了，比较普遍的做法是从IoC入手，了解容器注入的每一个环节，掌握大致的流程 由于使用的是Spring，所以在这里我们引入比较古老的xml配置文件进行bean的配置，首先定义一个bean: 配置描述bean的xml，核心只有一行： 这样一来就可以使用BeanFactory这个容器来注入bean并使用了： 本来有封装好的XmlBeanFactory，这一类现在已经被弃用了，所以采用了他的父类DefaultListableBeanFactory;当然，也可以使用更加方便和常用的ApplicationContext： 当然从xml文件读取bean的配置只是其中一种目前用的不多的加载方式，还有基于包扫描等加载bean的方法，此处仅为理解IoC的基本使用
2020-08-04鱼鱼
项目异常问题解决
项目异常问题解决这天 程序抛出了一个WARN日志： createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [43,844] milliseconds. 这意味着SHA1PRNG算法导致项目启动多花费了43秒，这是基于SHA-1算法实现且保密性较强的伪随机数生成器 1.从tomcat层面上解决： 在catalina.sh中加入这么一行：-Djava.security.egd=file:/dev/./urandom 2.从java层面解决 打开$JAVA_PATH/jre/lib/security/java.security这个文件，将下面的内容：
2019-02-28鱼鱼
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鱼鱼
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鱼鱼
