1.JDK7u21 com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl
简单来说, javaagent 是在class 被装在到ClassLoader之前对其拦截,插入自定义的监听字节码,可实现零侵入的监控,是APM的核心技术
大家好,美美今天给大家推荐一篇Java字节码增强技术的文章,在实际工作中有很多应用场景。
上篇文章我们说到阿里的诊断工具Arthas对方法和类的监控使用的是动态追踪技术,本文我们将介绍动态追踪技术Java Agent。
公司目前 Java 项目提供服务都是基于 Dubbo 框架的,而且 Dubbo 框架已经成为大部分国内互联网公司选择的一个基础组件。
远程服务调用(Remote procedure call)的概念历史已久,1981年就已经被提出,最初的目的就是为了调用远程方法像调用本地方法一样简单,经历了四十多年的更新与迭代,RPC 的大体思路已经趋于稳定,如今百家争鸣的 RPC 协议和框架,诸如 Dubbo (阿里)、Thrift(FaceBook)、gRpc(Google)、brpc (百度)等都在不同侧重点去解决最初的目的,有的想极致完美,有的追求极致性能,有的偏向极致简单。
Java Agent本质上可以理解为一个插件,该插件就是一个精心提供的Jar包,这个Jar包通过JVMTI(JVM Tool Interface)完成加载,最终借助JPLISAgent(Java Programming Language Instrumentation Services Agent)完成对目标代码的修改。
字节码编程在实际的业务开发(CRUD)中并不常用,但是随着网络编程,RPC、动态字节码增强技术和自动化测试以及零侵入APM监控的不断发展与大量使用,越来越多的技术需要使用到字节码编程。
总第495篇 2022年 第012篇 Sonic是美团内部一款用于热部署的IDEA插件。本文主要讲述Sonic的实现细节以及底层原理,从IDEA插件到自动化部署,再到沉浸式开发产品闭环,全方位讲述了Sonic在美团的落地与实践经验。目前业界对标的产品并不多,希望本文能对从事联调/开发/测试等相关方向的同学有所帮助或启发。 1 前言 1.1 什么是热部署 1.2 为什么我们需要热部署 1.3 热部署难在哪 1.4 Sonic可以做什么 1.5 技术产品落地和推广实践经验 2 整体设计方案 2.1 Sonic
前面文章介绍的 ASM 入门门槛还是挺高的,需要跟底层的字节码指令打交道,优点是小巧、性能好。Javassist 是一个性能比 ASM 稍差但是使用起来简单很多的字节码操作库,不需要了解字节码指令,由东京工业大学的数学和计算机科学系的教授 Shigeru Chiba 开发.
Javassist (Java Programming Assistant) makes Java bytecode manipulation simple. It is a class library for editing bytecodes in Java; it enables Java programs to define a new class at runtime and to modify a class file when the JVM loads it. Unlike other similar bytecode editors, Javassist provides two levels of API: source level and bytecode level. If the users use the source-level API, they can edit a class file without knowledge of the specifications of the Java bytecode. The whole API is designed with only the vocabulary of the Java language. You can even specify inserted bytecode in the form of source text; Javassist compiles it on the fly. On the other hand, the bytecode-level API allows the users to directly edit a class file as other editors.
Javassist是一个处理字节码的类库。Java字节码存储在一个叫做*.class的二进制文件中。每个class文件包含一个java类或者接口。
在字节码编程方面有三个比较常见的框架;ASM、byte-buddy、Javassist,他们都可以对这字节码进行操作,只是操作方式和控制粒度不同。
•JDK动态代理:运行期动态的创建代理类,只支持接口;•ASM:一个 Java 字节码操控框架。它能够以二进制形式修改已有类或者动态生成类。不过ASM在创建class字节码的过程中,操纵的级别是底层JVM的汇编指令级别,这要求ASM使用者要对class组织结构和JVM汇编指令有一定的了解;•javassist:一个开源的分析、编辑和创建Java字节码的类库(源码级别的类库)。javassist是jboss的一个子项目,其主要的优点,在于简单,而且快速。直接使用java编码的形式,而不需要了解虚拟机指令,就能动态改变类的结构,或者动态生成类;•bytebuddy:一个更高层次操作字节码的工具包。
AspectJ的缺点是,由于其基于规则,所以其切入点相对固定,对于字节码文件的操作自由度以及开发的掌控度就大打折扣。还有就是我们要实现的是对所有方法进行插桩,所以代码注入后的性能也是我们需要关注的一个重要的点,我们希望只插入我们想插入的代码,而AspectJ会额外生成一些包装代码,对性能以及包大小有一定影响。
运行报错:java.io.IOException: invalid constant type: 15
我开发的这个框架,有一个注解,当用户输入变量名,类名的时候,我这个框架可以为其自动生成一个对象,并加载到内存中供以后使用。
如果类是否被修改是在加载时确定的,用户必须让javassist与类加载器协作。 javassist可以与类加载器一起使用,以便在加载时修改字节码。 用户可以使用自定义版本的类加载器,也可以使用javassist提供的类加载器。
上节说了javaagent和javassist,其实javassist也是基于ASM实现的。一般人不懂得JVM指令的话,根本ASM搞不起来,也用到了访问者的设计模式,看起来跟咱们写代码不是一个套路,学
最近一个项目测试的时候,需要进行多个tomcat集群测试。 我本地用了一个新的tomcat, 然后把项目打好的war包扔到tomcat里面进行运行。 启动时出现一个异常:java.io.IOException: invalid constant type: 15 。
最近和不少小伙伴聊天,发现大部分小伙伴,其中可能就包括正在看文章的你和我,工作时间已经不短了,有些小伙伴工作3~5年了,有些甚至超过8年了。
import java.lang.reflect.Method; import java.util.Arrays; import java.util.stream.Collectors; import javassist.ClassPool; import javassist.CtClass; import javassist.CtMethod; import javassist.Modifier; import javassist.bytecode.CodeAttribute; import javass
在上一期讲解java的动态性的时候,我们主要提到了java中的反射机制,可以在java代码运行的时候,改变类的结构,属性等信息,而这一节我们通过另一种实现方式来讲解java的动态性,主要就是java的字节码操作。
在实际工作过程中,我们可以通过对Java的字节码进行插桩,以便拦截我们需要拦截的类和方法,对这些类和方法进行改造或者直接动态生成相应的类来实现拦截的逻辑。
在上一篇 Helloworld 中,我们初步尝试使用了 Javassist字节编程的方式,来创建我们的方法体并通过反射调用运行了结果。大致了解到创建在使用字节码编程的时候基本离不开三个核心类;ClassPool、CtClass、CtMethod,它们分别管理着对象容器、类和方法。但是我们还少用一样就是字段;CtFields,在这一章节中我们不止会使用字段,还会创建多个不同入参类型和返回值的学习。
在上一篇 「Helloworld」 中,我们初步尝试使用了 Javassist字节编程的方式,来创建我们的方法体并通过反射调用运行了结果。大致了解到创建在使用字节码编程的时候基本离不开三个核心类;ClassPool、CtClass、CtMethod,它们分别管理着对象容器、类和方法。但是我们还少用一样就是字段;CtFields,在这一章节中我们不止会使用字段,还会创建多个不同入参类型和返回值的学习。
http://www.javassist.org/tutorial/tutorial.html
最近将IDEA 2018.1版本更新到了2018.2版本,更新好后跑了一下之前的项目,结果就报错了,这个项目集成了spring data jpa。由于该错误有多种原因导致,在解决该错误的时候也花了一些时间,所以特别记录一下。关键的报错信息如下:
提到 JAVA 中的动态代理,大多数人都不会对 JDK 动态代理感到陌生,Proxy,InvocationHandler 等类都是 J2SE 中的基础概念。动态代理发生在服务调用方/客户端,RPC 框架需要解决的一个问题是:像调用本地接口一样调用远程的接口。于是如何组装数据报文,经过网络传输发送至服务提供方,屏蔽远程接口调用的细节,便是动态代理需要做的工作。RPC 框架中的代理层往往是单独的一层,以方便替换代理方式(如 motan 代理层位于 com.weibo.api.motan.proxy ,dubbo
Spring Cloud 项目中,很多功能都是用 aop去实现的,或者直接使用Java Agent。
案例简述 通过上一章节的介绍《嗨!JavaAgent》,我们已经知道通过配置-javaagent:文件.jar后,在java程序启动时候会执行premain方法。接下来我们使用javassist字节码增强的方式,来监控方法程序的执行耗时。
来源: https://blogs.sap.com/2016/03/09/java-bytecode-instrumentation-using-agent-breaking-into-java-application-at-runtime/
fastjson简单使用 User: package com.naihe; public class User { private String name; private int age; public User() {} public User(String name, int age) { this.name = name; this.age = age; } public String getName()
我想的方案是:直接获取某个接口下面所有的实现类的对象集合,方便以后只需要 实现这个接口,就能自动被加载执行。话不多说,说说我的实现方案。
上一篇提到过@Adaptive注解的作用:被@Adaptive修饰的类实际上是一个装饰类。被@Adaptive修饰的方法则会生成一个动态代理类,而根据模板生成的类则需要通过动态编译由字节流被编译成动态代理类。本文主要讲的就是dubbo的动态编译。 dubbo-spi的扩展装饰类是通过ExtensionLoader.getAdaptiveExtension来获取,内部则进行了动态编译。核心代码如下:
1.fastjson简单使用 User: package com.naihe; public class User { private String name; private int age; public User() {} public User(String name, int age) { this.name = name; this.age = age; } public String getNam
到本章为止已经写了四篇关于字节码编程的内容,涉及了大部分的API方法。整体来说对 Javassist 已经有一个基本的使用认知。那么在 Javassist 中不仅提供了高级 API 用于创建和修改类、方法,还提供了低级 API 控制字节码指令的方式进行操作类、方法。
在前文中,介绍了Instrumentation中的premain功能, 这次再一起看下它的agentmain功能.
前面两篇文章介绍了 Gradle自定义插件以及扩展配置的用法。 今天我们来看一下一个具体的应用场景,动态编译。我们将尝试在编译期间修改class文件。
字节码编程插桩这种技术常与 Javaagent 技术结合用在系统的非入侵监控中,这样就可以替代在方法中进行硬编码操作。比如,你需要监控一个方法,包括;方法信息、执行耗时、出入参数、执行链路以及异常等。那么就非常适合使用这样的技术手段进行处理。
Javassist 是一个开源的分析、编辑和创建Java字节码的类库. 其主要优点在于简单快速. 直接使用 java 编码的形式, 而不需要了解虚拟机指令, 就能动态改变类的结构, 或者动态生成类.
大家在日常抓包,可能用的比较多的是burpsuite,对于我个人而言,我有时也会遇到这款工具,charles,下载地址是:https://www.charlesproxy.com/ 。工具使用不是本文重点。
前文提到,动态代理机制使用了反射,Spring 中的 AOP 由于使用了动态代理,所以也相当于使用了反射机制。那么,代理是什么?动态代理又是什么?动态代理中是如何使用反射的?全文脉络思维导图如下:
最近帮助同事解决了一个比较棘手的问题,一路采坑的过程比较有意思。在此记录下来。(PS:主要原因是项目比较大,我们只有整个Android项目部分业务侧代码的开发权限。所以解决问题的一些解决问题的常规手段无法使用。)
前面学习的cc链都是基于commons-collections:commons-collections的3.1-3.2.1这几个版本的,但后面有了新的分支org.apache.commons:commons-collections4的4.0版本。可以发现groupId和artifactId都发生了改变,也就是形成了两个分支。这是因为commons-collections4不是用来替换commons-collections的一个新版本,而是修复旧的commons-collections的⼀些架构和API设计上的问题的一个拓展。两者的命名空间并不冲突,都可以放在同一个项目中。
领取专属 10元无门槛券
手把手带您无忧上云