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鱼鱼

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鱼鱼

Springboot源码原理:从启动方法看配置加载

Springboot源码原理:从启动方法看配置加载首先看一个springboot项目的配置,我们可以定义一个application.yml,对于不同的环境有时也通过profile配置项指定不同的配置文件(譬如application-dev.yml),也可以通过命令行覆写具体的VM options配置项(举个栗子,启动时执行 java -jar xxx.jar --server.port=8080),此文讲解这些配制的读取原理 整体配置项的优先级从高到低为: 命令行配置; 系统属性(System.getProperties()) 系统环境变量 jar包外的主配置文件(带有) jar包内的主配置文件 jar包外的次要配置文件(由spring.profile指定的)
Springboot源码原理:从启动方法看配置加载2021-03-09鱼鱼

过滤器、拦截器、监听器和AOP

过滤器、拦截器、监听器和AOP用这篇文章来梳理一下这些杂七杂八的Spring MVC中的基础概念,顺便讲一下在项目中的一些基本使用和常见应用(其实主要是针对AOP的),至于使用他们实现具体的功能,后续可能会独立写出来(谁知道呢) 执行的顺序: 项目初始化:filter:init()->filter:doFilter()->preHandle->Controller->postHandle->afterComplition ->destory() 过滤器(Filter),由servlet提供,拦截URL(其实是servlet),经过代理,执行想要的方法,最基本的使用是集成Filter类并重写方法,因为是从url层面上直接拦截,可以有很多用途,比如用于用户身份校验,比如某些页面需要有用户权限才能访问,就可以利用过滤器进行拦截,一些安全框架的鉴权本身也是过滤器的实现
过滤器、拦截器、监听器和AOP2020-03-01鱼鱼

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
Redis原理-源码解析:数据结构3 hash 2020-11-29鱼鱼

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的基本使用
Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听2020-08-04鱼鱼

多线程应用提高(IV) 线程安全的集合类

多线程应用提高(IV) 线程安全的集合类在Java中的数据结构一篇中,列举了Java中一些常见的集合,此文主要梳理线程安全的相关集合 我们知道,当一个实例对象只能被一个线程访问时(线程私有),无论如何都不会有线程安全的问题,但在多线程的情境下,多个线程操作同一个对象时,可能会出现更新丢失、读写数据不同步、计数击穿等现象,此时这种操作就是非线程安全的 相应地,线程安全的集合有这样的特点:在多个线程操作同一集合时,能保证每一步操作都是安全的,与串行执行的结果一致,不会出现数据不同步等预料之外的问题 可以先看这个小例子Java-lab/ListT.java at master · fishstormX/Java-lab,我在里面解释了
多线程应用提高(IV) 线程安全的集合类2019-07-13鱼鱼

Netty

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

项目异常问题解决

项目异常问题解决这天 程序抛出了一个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鱼鱼

Java排坑指南(I)jmap jstack jstat等的使用

Java排坑指南(I)jmap jstack jstat等的使用运用一些Java自带的可执行jar可以从内存的角度更轻松的排除项目中的问题,我们可能会遇到一些不常见却相对很致命的问题,例如: 某些web项目CPU跑到了100%并且飙高不下(一般来说,web应用都为IO密集应用,不太可能出现cpu高占用的情况) 项目中线程出现阻滞、阻塞(网络请求响应速度明显变慢,甚至因为死锁彻底出现阻塞等) 极可能由内存泄漏引发的不明原因的 OOM(没有预兆的或是基础逻辑问题的内存溢出) 当以上问题发生时,通过代码或是日志其实很难定位到原因所在,因为这一般是基于环境或资源导致的全局性问题,通常很难定位,这时可以通过使用Java自带的性能调优jar包更便捷的定位问题(如果没有配置环境变量,可以在jdk的bin目录下找到他们的jar包)
Java排坑指南(I)jmap jstack jstat等的使用2020-11-28鱼鱼

浅谈代理-动态代理

浅谈代理-动态代理我们可以很轻松的实现一个简单的代理 实现静态代理是个很简单的事情,最基础的代理只需要定义一个接口(虽然不是必要,但这显然才是标准的设计)、一个被代理类和一个代理类,例如: 定义一个接口: 一个实现类: 和一个代理类: 实际使用时,我们是去调用HelloWorldProxy的方法,其将作为HelloWorld的代理实现 此种方式直接实现的代理太过于死板,因为每一种代理行为都要制定一个代理类,我们熟知的很多基于代理的实现(譬如AOP、事务)显然不可能用静态代理的方式针对每一处类切点都覆写一个代理类,这种时候就需要动态代理 我们所熟知的相当多的框架均基于动态代理开发,JDK本身基于反射(java.lang.reflect)提供了动态代理,我们只需定义代理的行为,而对于代理类的范围并不是固定值
浅谈代理-动态代理2020-10-13鱼鱼

Kafka服务端集群原理

Kafka服务端集群原理kafka是家喻户晓的消息队列,也因“纯粹”而闻名(高性能高吞吐、扩展较少较为简单),此篇文章整理Kafka的基本架构,将按照Kafka的版本迭代分别展示架构的演进(截至版本3.0) 我们在这里暂且只讨论Kafka服务端,对于生产者和消费者的逻辑简单带过 扫盲一下Kafka的部分概念: Producer mq生产者通用叫法 作为消息的生产者,在生产完消息后需要将消息投送到指定的目的地(某个topic的某个partition) Producer可以根据指定选择partition的算法或者是随机方式来选择发布消息到哪个partition; Consumer mq生产者通用叫法 消息消费者,向Kafka broker读取消息的客户端;,负责订阅和消费消息
Kafka服务端集群原理2022-03-10鱼鱼
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}