并发之AQS全解析
并发之AQS全解析我们知道juc(java.util.concurrent)包下有很多实用的类，提供了很多并发工具，例如线程池、原子类、并发工具、信号量工具、锁等，可以说基本实现都为悲观锁，底层原理基本都使用了AQS(AbstractQueuedSynchronizer)，AQS不是一种概念，是并发中实打实的工具类 本篇文章针对AQS做解析 AQS是多线程访问共享资源的同步器框架 AQS的资源可以是独占的也可以是共享的 我们先来简单看一下它的使用方式和ApI（因为是抽象类，是不能直接使用的）,下图是AQS的整体脉络 AQS核心就是一个状态值state，同时维护了一个线程的阻塞队列，队列的节点为有两种状态：SHARED(共享)和EXCLUSIVE(独占)，节点状态有五种：
![并发之AQS全解析]()
2021-03-12鱼鱼
Netty
NettyNIO相比IO有诸多利处，但平常开发中若是直接使用原生NIO进行业务开发是很不可取的，否则将面临臃肿而晦涩难懂的代码 所以日常开发中我们会时常使用封装了NIO操作代码的Netty来实现NIO操作 Netty是一个异步事件驱动的网络应用框架，用于快速开发可维护的高性能服务器和客户端
![Netty]()
2019-05-11鱼鱼
动态路由数据源（多租户）解决方案
动态路由数据源（多租户）解决方案当下有很多服务都使用了多数据源，或是出于跨库查询或是分库分表、读写分离等，多数据源解决方案早已不是稀罕事 常见的解决方案包括使用多数据源框架(例如Shareding-Jdbc)、在数据库端做代理（例如MYCAT）、对于固定的几个数据源连接，也可以直接手动配置多个数据源，这种相关处理有很多源码，我在github上也有简单的实现：fishstormX/dynamicDataSource: 动态数据源的实现，基于maven自定义多模块骨架 Spring Boot2.0.x，本文实现的是动态数据源，主要为了解决 多租户问题（不同的用户群组有不同的数据源和配置，强调数据的隔离性） 本文技术能实现的是动态数据源，基于Spring框架，即能够将注入的Datasource根据租户不同使用不同的来源，同时根据租户增减动态的增删和缓存数据源（增是因为会有新增租户可能使用到项目启动后的数据源，减是因为租户数不可预料，不可直接缓存所有的数据源）
2021-01-07鱼鱼
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鱼鱼
Spring MVC源码和设计思想1 DispatcherServlet
Spring MVC源码和设计思想1 DispatcherServlet此篇文章是个人通过阅览Spring MVC源码的学习过程记录，包含Spring MVC的关键细节源码设计和一些设计上的tips，更近似于一种意识流的记录方式，锚点设置可能也有些乱，零零散散的点我日后有时间会统一总结起来 Restful风格的Http有八种请求方式，除了最常使用的Get与Post还有Head、Put、Delete、Options、Trace、Connect 在Restful接口的设计中，请求方方式的语义性很强，我们时常用他约束接口请求的行为，请求类型的语义： OPTIONS获取服务器支持的HTTP请求方法； HEAD跟get很像，但是不返回响应体信息，用于检查对象是否存在，并获取包含在响应消息头中的信息
![Spring MVC源码和设计思想1 DispatcherServlet]()
2019-06-03鱼鱼
浅谈锁机制、主流锁设计方案
浅谈锁机制、主流锁设计方案本文旨在探讨通用的锁机制实现逻辑，以Java中常见的锁实现为例 本文提到的锁，是指通过限制并发/并行访问所添加的安全措施，本质上是通过限制线程/进程同时更改数据或是读取数据与写入数据产生时序差从而造成数据问题 锁机制中，有一些常见特性： 可重入性 指同一线程/进程携带相同的标识可以反复多次加锁，每次加锁和释放锁对应的重入次数+1/-1； 读写锁/独享共享 是锁的不同运作模式，分为读写锁，读锁与写锁、写锁与写锁是互斥的，但多个线程/进程可以同时对一个逻辑添加读锁，独享共享是另一种叫法 公平性 锁分为 公平锁和非 公平锁， 公平锁指锁释放和获取的顺序严格按照索取的顺序，非 公平锁则是等待锁的对象共同进行锁释放机会的争抢
![浅谈锁机制、主流锁设计方案]()
2024-10-15鱼鱼
ooo
ooo拆箱：包装类-》基本数据类型 Integer Byte -127- 127是以缓存数组指向相同对象，之外的默认new 模块化 完全解耦 #预编译 $直接用 $内容手动干涉 Mybatis有三种基本的Executor执行器，SimpleExecutor、ReuseExecutor、BatchExecutor SimpleExecutor：每执行一次update或select，就开启一个Statement对象，用完立刻关闭Statement对象 ReuseExecutor：执行update或select，以sql作为key查找Statement对象，存在就使用，不存在就创建，用完后，不关闭Statement对象，而是放置于Map
内，供下一次使用
2019-04-02鱼鱼
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
![JVM源码解析(2) ContextClassLoader与ClassUtil.forName()方法浅析]()
2020-08-16鱼鱼
代理与nginx
代理与nginx代理指接受请求但是不由代理服务器自己处理请求而是直接转发给指定服务器（或是根据负载均衡算法转发给集群部署中的某一台服务器），然后由代理服务器接收请求结果并返回给客户端 指客户端的代理处理方式，指用户通过代理服务器访问指定的网站、服务，最常见的应用是翻墙，并且使用这种方式可以使客户端匿名访问 指服务端的代理处理方式，多个用户在访问网站服务时，实际访问的是反向代理服务器(如nginx)，反向代理服务器将请求内容转发给服务集群，最常用于服务器集群负载均衡和避免内网信息暴露 总之，正向代理是对服务端隐藏了客户端信息，反向代理则正相反，有一张图可以很好地概括这两个代理概念(图源知乎，侵删)
2019-05-11鱼鱼
网络协议面面观：TCP/IP协议组，TCP与UDP
网络协议面面观：TCP/IP协议组，TCP与UDP日常中的网站应用交互绝大部分都是基于TCP/IP协议栈构建的，而TCP/IP就是通信常见的protocol(协议)组，是一类协议的简称，利用这篇文章总结一些常见的TCP/IP网络协议簇以及着重一下两个常见的传输层协议TCP和UDP，扫一下盲 OSI参考模型是ISO(国际标准化组织)指定的网络互联七层模型，与此对比的还有互联网界针对TCP/IP协议簇提出的四层模型 相比之下，OSI七层模型的应用面很窄，且是一种理论模型，TCP/IP则是一种实施标准 一般使用四层模型来表达协议归属，所以此处不详细介绍七层模型的内容，只是简单的与四层协议做对比，两者对比： 应用层 通过这个TCP/IP模型，整体的数据流向是发送方自顶向下然后在接收方自底向上的，即：
2020-03-03鱼鱼
对多线程的执行效率探究——合理的任务并发拆分
对多线程的执行效率探究——合理的任务并发拆分通常，我们选择多线程执行任务有两个理由，一是复杂任务采用多线程处理能够在发生并发时让用户减少等待也能防止阻塞，一是充分利用空闲时间，提高任务处理的效率，就后者而言，此处探讨不考虑客户端并发是否有必要把一个任务拆分成多线程来处理 为了探究多线程的效率问题，我做了一个实验，将不同种类的任务分别用单线程和多线程执行，同时也试验了不同种类的锁机制 测试基于Java 8的版本，希望看到总结可以直接点击到文末 开启五个线程执行任务，设定了足够次数的循环输出，输出的数字和当前线程，利用System.currentTimeMillis()统计任务用时 (代码略)以下是相同任务在不同环境下执行多次的平均执行时间
2019-12-09鱼鱼
算法：Trie(前缀树、字典树）
算法：Trie(前缀树、字典树）前缀树(Trie，又称字典树)是一种功能倾向性很强的数据结构，通过对词汇的前缀做数结构，很容易实现查询、前缀词推荐系统，例如，我们将如下多个单词放入树结构中： [apple,bat,bee,cat,cap,car]，最终生成的前缀树结构为 通过深度递归，我们很容易用较小的时间复杂度判断出符合前缀的单词在不在 假设Trie的字符集范围是固定的，并且范围不大，例如是上面的纯英文字符，假设忽略大小写总共为26个，可以选择使用桶结构进行存储，即每一个Node都是一个长度为26的bucket数组 这样看来，Trie的结构并不复杂，只通过循环不断提高深度进行遍历即可 假定字符集的范围是未知的，或者范围很大（比如中文汉字），就要放弃使用bucket结构，而是通过一个Map维护，这里使用树结构TreeMap，key为相应节点的字符
2021-01-19鱼鱼
