2023年3月

前端表格控件
SpreadJS
推出了新的功能集算表功能。集算表 (Table Sheet)是一个具备高性能渲染、数据绑定功能、公式计算能力的数据表格,通过全新构建的关系型数据管理器结合结构化公式,在高性能表格的基础上提供排序、筛选、样式、行列冻结、自动更新、单元格更新等功能。

什么是集算表(Table Sheet
)?

集算表是一个具有网络状行为和电子表格用户界面的快速数据绑定表的视图。

众所周知Excel的工作表(Work Sheet)是一个自由式布局,基于单元格(Cell Base)的表格,适用于一些松散式的数据布局展示,布局上来说非常灵活,但对于固定格式的大批量数据展示,不具备优势。

集算表不同于Excel的工作表,它是一个基于列(Column Base)的网状表格(Grid),适用于展示规则数据。同时它还具备了Excel工作表(Work Sheet)的用户界面和部分常见操作。并且支持Excel的部分计算功能。同时结合SpreadJS数据绑定的功能,对于大量固定格式的数据(例如数据库的表格)可以快速在前端进行展示。

集算表的特点正如它的名字的三个字:集,算,表:

l  集(Data Manager):

集的意思就是数据集记和管理。集算表在前端构建了一个叫做Data Manager的数据管理模块。该模块可以简单理解为一个前端的数据库,Data Manager负责与远端的数据中心进行通信,拉取远端的数据。在前端处理数据,例如数据表的定义,表间关系等。同时Data Manager还负责处理数据的变形,例如分组,切片,排序,过滤等。

l  算(Calculation Engine):

集算表本身基于SpreadJS网络结构化数据的计算引擎Calculation Engine。Calculation Engine定义不同的上下文计算层级,不同与SpreadJS中工作表(Work Sheet)基于单元格或者区域(Range)的计算层级,集算表(Table Sheet)的上下文层级是基于行级,组级,数据级。

同时通过Calculation Engine的计算串联,使得集算表(Table Sheet)与工作表(Work Sheet)之间可以进行数据串联。这使得计算表不是一个独立存在,它可以与工作表结合使用,相互配合以适应更多的需求。

l  表(Table Sheet):

整个Table Sheet分为三层:渲染层,数据层,功能层。

渲染层复用了工作表(Work Sheet)的渲染引擎,具备双缓冲画布等高性能的优势。

数据层直连Data Manger,无需建立数据模型,相交SpreadJS更加快速。

功能层不同于传统表格(Grid),将底层结构化数据进行改造,在支持增删改查等基本功能的基础上,还额外支持了大部分工作表(Work Sheet)的对应功能,如样式,条件格式,数据验证,计算列等。

在数据底层,保证上述功能支持的基础上,还能保证数据的结构化,而非松散的数据结构。

集算表的架构:

Data Manager负责拉取远端数据,远端数据源可以是Rest API、OData、GraphQL、Local。Data Manager在拉取数据源之后会根据其中的定义构建数据表(Data Source),该表结构与数据库中的表结构类似。之后通过这些表来定义对应的数据视图(View),视图中定义了展示的结构以及计算列,关系列的添加。最终将不同的视图(View)绑定在不同的Table Sheet上。Table Sheet负责对所有的视图进行展示和操作。Calc Engine在Data Manager上工作,而非直接工作在Table Sheet上,这是为了更方便的去支持集算表与普通工作表之间的公式引用。这使得集算表与普通工作表之间产生“化学效应“,例如下面的示例:

在创建了集算表之后可以在普通的工作表中直接通过公式引入集算表的表格中的数据。这样可以做到通过集算表对数据进行展示,同时通过工作表的功能,对展示的结果进行数据分析。



甚至可以直接引用集算表中的数据当做数据数据源,创建数据透视表。



集算表的性能:

集算表是基于Column进行数据存储,相较于基于Row的存储结构,在筛选和计算方面有很大的优势。

通过性能测试,我们可以了解到,对于100W行级别的数据,集算表

从发送请求加载数据到将表格绘制完毕总共的耗时是大约5秒钟。

筛选数据花费时间在50ms左右(Filter country == "UK")。

100W行数据排序花费时间在5S左右(Sort birthday == "Ascending")。

对100W行数据添加计算列,对每行数据进行计算,花费时间不明显(总计时间4807ms,但该事件包含了数据加载,绘制的总时间,对比之前的测试结果基本在4800ms左右。故添加计算列计算花费的时间不明显,可忽略不计)。

如果想要了解更多SpreadJS产品特性或者查看性能测试示例,可访问下方地址。

https://en.onboarding.grapecitydev.com/spreadjs/feature-demo/web/tableSheet/performance.html

论文信息

论文标题:CosFace: Large Margin Cosine Loss for Deep Face Recognition
论文作者:H. Wang, Yitong Wang, Zheng Zhou, Xing Ji, Zhifeng Li, Dihong Gong, Jin Zhou, Wei Liu
论文来源:2018 IEEE/CVF Conference on Computer Vision and Pattern Recognition
论文地址:
download

论文代码:
download

引用次数:1594

1 介绍

当前提出的损失函数缺乏良好的鉴别能力,所以本文基于 “最大化类间方差和最小化类内方差” 的思想提出了 大边际余弦损失(LMCL)。

2 方法

2.1 引入

$\text{Softmax}$ 损失函数【指交叉熵损失函数】:

$L_{s}=\frac{1}{N} \sum_{i=1}^{N}-\log p_{i}=\frac{1}{N} \sum_{i=1}^{N}-\log \frac{e^{f_{y_{i}}}}{\sum_{j=1}^{C} e^{f_{j}}}    \quad\quad(1)$

其中,

$f_{j}=W_{j}^{T} x=\left\|W_{j}\right\|\|x\| \cos \theta_{j}$

Note
:$\theta_{j}$ 代表了 权重向量 $W_{j}$ 和 $x$ 之间的夹角;

分类任务的期望,是使得各个类别的数据均匀分布在超球面上。

NSL 损失
:【 固定权重向量 $W$ 的模长 $\|W\|=s$ 和特征向量 $x$ 的模长 $\|x\|=s$】

$L_{n s}=\frac{1}{N} \sum_{i}-\log \frac{e^{s \cos \left(\theta_{y_{i}, i}\right)}}{\sum_{j} e^{s \cos \left(\theta_{j, i}\right)}}  \quad\quad(3)$

通过固定 $\|x\|=s$ 消除径向的变化,使得模型在角空间中学习可分离的特征。

例如,考虑二分类的情况,设 $\theta_{i}$ 表示特征向量与类 $C_{i}$($i = 1,2$)权重向量之间的夹角。NSL 强制 $C_{1}$ 的 $\cos \left(\theta_{1}\right)>\cos \left(\theta_{2}\right)$,$C_{2}$ 也是如此,因此来自不同类的特性被正确地分类。

由于 NSL 学习到的特征没有足够的可区分性,只强调正确的分类。所以,本文在分类边界中引入余弦间隔,纳入 Softmax 的余弦公式中。

为开发一个大间隔分类器,进一步需要 $\cos \left(\theta_{1}\right)-m>\cos \left(\theta_{2}\right) $ 及 $\cos \left(\theta_{2}\right)-m>\cos \left(\theta_{1}\right)$,其中 $m \geq 0$ 是一个固定参数来控制余弦间隔的大小。由于$\cos \left(\theta_{i}\right)-m$ 低于 $\cos \left(\theta_{i}\right)$,因此对分类的约束更加严格,推广到多类:

${\large L_{l m c}=\frac{1}{N} \sum_{i}-\log \frac{e^{s\left(\cos \left(\theta_{y_{i}, i}\right)-m\right)}}{e^{s\left(\cos \left(\theta_{y_{i}, i}\right)-m\right)}+\sum_{j \neq y_{i}} e^{s \cos \left(\theta_{j, i}\right)}}} \quad\quad(4)$

其中,

$\begin{array}{l}W =\frac{W^{*}}{\left\|W^{*}\right\|}\\x =\frac{x^{*}}{\left\|x^{*}\right\|}\\\cos \left(\theta_{j}, i\right) = W_{j}^{T} x_{i}\end{array} \quad\quad(5)$

2.2 方法对比

$\text{Softmax}$ 的决策边界:
【$magin< 0$】

$\left\|W_{1}\right\| \cos \left(\theta_{1}\right)=\left\|W_{2}\right\| \cos \left(\theta_{2}\right)$

边界依赖于权重向量的大小和角度的余弦,这导致在余弦空间中存在一个重叠的决策区域。

$\text{NSL}$ 的决策边界:
【$magin= 0$】

$\cos \left(\theta_{1}\right)=\cos \left(\theta_{2}\right)$

通过去除径向变化,NSL 能够在余弦空间中完美地分类测试样本。然而,由于没有决策边际,它对噪声的鲁棒性并不大:决策边界周围的任何小的扰动都可以改变决策。

$\text{A-Softmax}$ 的决策边界:

$\begin{array}{l}C_{1}: \cos \left(m \theta_{1}\right) \geq \cos \left(\theta_{2}\right) \\C_{2}: \cos \left(m \theta_{2}\right) \geq \cos \left(\theta_{1}\right) \end{array}$

对于 $C_{1}$,需要 $\theta_{1} \leq \frac{\theta_{2}}{m}$。然而问题是 $\text{Margin}$ 随着 $W_1$ 和 $W_2$ 之间的夹角发生变化,如果两个类的样本区分难度很大,导致 $W_1$ 和 $W_2$ 夹角很小,可能会出现 $\text{Margin}$ 很小的情况。

$\text{LMCL }$ 的决策边界:

$\begin{array}{l}C_{1}: \cos \left(\theta_{1}\right) \geq \cos \left(\theta_{2}\right)+m \\C_{2}: \cos \left(\theta_{2}\right) \geq \cos \left(\theta_{1}\right)+m\end{array}$

因此,$\cos \left(\theta_{1}\right)$ 被最大化,而 $\cos \left(\theta_{2}\right)$ 被最小化,使得 $C_{1}$ 执行大边际分类。$\text{Figure 2}$ 中 $\text{LMCL}$ 的决策边界,可以在角度余弦分布中看到一个清晰的 $\text{Margin}$( $\sqrt{2} m$)。这表明 LMCL 比 NSL 更健壮,因为在决策边界(虚线)周围的一个小的扰动不太可能导致不正确的决策。余弦裕度一致地应用于所有样本,而不考虑它们的权值向量的角度。

2.3 特征归一化

特征归一化的必要性包括两个方面:

    • 没有归一化之前的 $\text{Softmax}$ 损失函数会潜在地学习特征向量的 $L_{2}$ 模长和角度余弦。由于 $L_{2}$ 模长的增大,会一定程度上降低损失函数的值,这样会削弱余弦约束;
    • 同时希望所有数据的特征向量都具有相同的二范数,以至于取决于余弦角来增强判别性能。在超球面上,来自相同类别的特征向量被聚类在一起,而来自不同类别的特征向量被拉开;

比如假设特征向量为 $\mathrm{x}$,让 $\cos \left(\theta_{i}\right)$ 和 $\cos \left(\theta_{j}\right)$ 代表特征与两个权重向量的余弦,如果没有归 一化特征,损失函数会促使 $\|x\|\left(\cos \left(\theta_{i}\right)-m\right)>\|x\|\left(\cos \left(\theta_{j}\right)\right)$ ,但是优化过程中如果 $\left(\cos \left(\theta_{i}\right)-m\right)<\cos \left(\theta_{j}\right)$ ,为了降低损失函数,用 $\|x\|$ 的增加来换取损失函数的降低也是很可能的,所以会导致优化问题产生次优解。
此外尺度参数 $s$ 应该设置足够大,对于 NSL,太小的 $s$ 会导致收敛困难甚至无法收敛。在 LMCL,我 们需要设置更大的 $s$ 才能保证在预设的 Margin 以及在足够大的超球面空间来学习特征。
接下来分析 $s$ 应该有一个下界来保证获得期望的分类性能。给定归一化的学习特征向量 $x$ 和单位权重向量 $W$,用 $C$ 表示类别总数,假设学习到的特征分别位于超平面上,以相应的权重向量为中心。$p_{W}$  表示类里面期望的最小的后验概率(也就是与 $W$ 重合的特征的后验概率), $s$  下界为:

$s \geq \frac{C-1}{C} \log \frac{(C-1) P_{W}}{1-P_{W}}  \quad\quad(6)$

可以分析出,如果在类别数保持一定情况下,想要得到最佳的 $p_{W}$,$\mathrm{~s}$ 要足够大。此外,如果固定 $p_{W}$,随着类别数的增加,也需要增大 $\mathrm{s}$ 值,因为类别数的增加会提升分类的难度。

2.4 LMCL的理论分析

选择合适的 $\text{Margin}$ 很重要,分析超参数 $\text{Margin}$ 的理论界限很有必要。

考虑二分类问题,类别分别是 $\mathrm{C}_1$  和 $\mathrm{C}_2$,归一化特征为 $x$,归一化权重向量 $W_{i}$,$W_{i}$ 与 $x$ 之间的夹角为 $\theta_{i}$,对于NSL而言,决策边界 $\cos \left(\theta_{1}\right)=\cos \left(\theta_{2}\right)$ 等同于 $W_{1}$ 和 $W_{2}$ 的角平分线。对于 $\mathrm{LMCL}$,对于 $\mathrm{C}_1$ 类样本它会驱使决策边界 $\cos \left(\theta_{1}\right)-m=\cos \left(\theta_{2}\right)$ 的形成,这样会导致  $\theta_{1}$ 比 $\theta_{2}$ 小的多。因此类间差异扩大,类内差异缩小。

我们发现 Margin 与 $W_{1}$ 和 $W_{2}$ 之间的角度有关系。当 $W_{1}$ 和 $W_{2}$ 都给定的时候,余弦 Margin 具有范围的限制。具体而言,假设一个场景,即属于第 $i$ 类的所有特征向量与第 $i$ 类的相应权重向量 $W_{i}$ 完全重叠。 换句话说,每个特征向量都与类 $i$ 的权重向量相同,并且显然,特征空间处于极端情况,其中所有特征向量都位于其类中心,在这种情况下,决策边界的 Margin 已最大化(即,余弦 Margin 的严格上限)。

理论上 $m$ 的范围是: $0 \leq m \leq\left(1-\max \left(W_{i}^{T} W_{j}\right)\right), i \neq j$ ,$\text{softmax}$ 损失尝试使来自任意两个类的两个权重之间的角度最大化,以执行完美分类。很明显,softmax 损失的最佳解决方案应将权重向量均匀分布在单位超球面上。引入的余弦 Maging 的可变范围可以推断如下:

$\begin{array}{l}0 \leq m \leq 1-\cos \frac{2 \pi}{C}, \quad(K=2) \\0 \leq m \leq \frac{C}{C-1}, \quad(C \leq K+1) \\0 \leq m \ll \frac{C}{C-1}, \quad(C>K+1)\end{array}   \quad\quad(7)$

$C$ 是训练类别数,$K$ 是学习特征的维度。这个不等式意味着随着类别数目越多,$\text{Margin}$ 的设置上界相应减少,特别是类别数目超过特征维数,这个上界允许范围变得会更小。在实践中 $m$ 不要取理论上界,理论上界是一种理想的情况(所有特征向量都根据相应类别的权重向量居中在一起),这样当 $m$ 太大模型是不会收敛的,因为余弦约束太严格,无法在现实中满足。其次过于严格的余弦约束对噪声数据非常敏感,影响整体性能。

作者做了一个小实验验证了这些思想,取了 8 个人的人脸数据,用原始的 $\text{Softmax}$ 损失和本文提出的 LMCL 损失函数训练样本,然后将特征提取并可视化,$m$ 应该小于 $1-\cos \left(\frac{2 \pi}{8}\right)$,大约 $0.29$ ,分 别设置 $ \mathrm{m}=0,0.1,0.2$  三种情况,可以观察到原始的 $\text{softmax}$ 损失在决策边界上产生了混淆,而提出的 LMCL 则表现出更大的优势。随着$m$ 的增加,不同类别之间的角度 $\text{Margin}$ 已被放大。

一:背景

1. 讲故事

最近收到了两起程序崩溃的dump,查了下都是经典的
double free
造成的,蛮有意思,这里就抽一篇出来分享一下经验供后面的学习者避坑吧。

二:WinDbg 分析

1. 崩溃点在哪里

windbg 带了一个自动化分析命令
!analyze -v
可以帮助我们找到崩溃时的程序指令地址以及崩溃的代码,这对我们分析问题非常有帮助。


0:090> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************
CONTEXT:  (.ecxr)
rax=00007ffec265d6e0 rbx=00000000c0000374 rcx=00000053653fe4f0
rdx=00007ffec1d3e9a0 rsi=0000000000000001 rdi=00007ffed7b827f0
rip=00007ffed7b1b349 rsp=00000053653fed10 rbp=000001c14fd20000
 r8=000001c11957d9a0  r9=0000000000000033 r10=000001c453dbc7f0
r11=00007ffeb94db004 r12=0000000000000001 r13=000001c12e8526d0
r14=0000000000000000 r15=000001ce25531c60
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
ntdll!RtlReportFatalFailure+0x9:
00007ffe`d7b1b349 eb00            jmp     ntdll!RtlReportFatalFailure+0xb (00007ffe`d7b1b34b)
Resetting default scope

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 00007ffed7b1b349 (ntdll!RtlReportFatalFailure+0x0000000000000009)
   ExceptionCode: c0000374
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 00007ffed7b827f0

PROCESS_NAME:  w3wp.exe
...

熟悉 windows ntheap 的朋友应该知道,
ExceptionCode: c0000374
是经典的
堆破坏
状态码,那到底是谁破坏了呢?

2. 到底是谁破坏了NT堆

windows 给了 ntheap 强大的调试支持,默认开启了
Termination on corruption
破坏检测,也就是说当你使用
!heap -s
的时候会显示具体破坏的详情记录,输出如下:


0:090> !heap -s


************************************************************************************************************************
                                              NT HEAP STATS BELOW
************************************************************************************************************************
**************************************************************
*                                                            *
*                  HEAP ERROR DETECTED                       *
*                                                            *
**************************************************************

Details:

Heap address:  000001c14fd20000
Error address: 000001ce25531c50
Error type: HEAP_FAILURE_BLOCK_NOT_BUSY
Details:    The caller performed an operation (such as a free
            or a size check) that is illegal on a free block.
Follow-up:  Check the error's stack trace to find the culprit.


Stack trace:
Stack trace at 0x00007ffed7b82848
    00007ffed7abe109: ntdll!RtlpLogHeapFailure+0x45
    00007ffed7acbb0e: ntdll!RtlFreeHeap+0x9d3ce
    00007ffeb093276f: OraOps12!ssmem_free+0xf
    00007ffeb0943077: OraOps12!OpsMetFreeValCtx+0xd7
    00007ffeb093cdd8: OraOps12!OpsDacDispose+0x2b8
    00007ffe655e4374: +0x655e4374

LFH Key                   : 0x5baf44f8068da60f
Termination on corruption : ENABLED
          Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                            (k)     (k)    (k)     (k) length      blocks cont. heap 
-------------------------------------------------------------------------------------
000001c14fd20000 00000002 1021576 964388 1020020  19222  6063   166    2    82f   LFH
000001c14fc70000 00008000      64      4     64      2     1     1    0      0      
...

上面的
Error type: HEAP_FAILURE_BLOCK_NOT_BUSY
表示是一个 double free,从
Stack trace
看是
OpsDacDispose
方法造成的,应该和 Oracle 相关,这就比较迷了。。。

3. 是托管层触发的吗

是不是托管层触发的呢?这就需要理解 Windows 独有的 SEH 异常处理机制,也就是说 Windows 的异常都会在
内核态
走一圈,画个图如下:

只要找到
t1
时刻的崩溃点,然后观察线程栈即可,代码如下:


0:090> .ecxr
rax=00007ffec265d6e0 rbx=00000000c0000374 rcx=00000053653fe4f0
rdx=00007ffec1d3e9a0 rsi=0000000000000001 rdi=00007ffed7b827f0
rip=00007ffed7b1b349 rsp=00000053653fed10 rbp=000001c14fd20000
 r8=000001c11957d9a0  r9=0000000000000033 r10=000001c453dbc7f0
r11=00007ffeb94db004 r12=0000000000000001 r13=000001c12e8526d0
r14=0000000000000000 r15=000001ce25531c60
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
ntdll!RtlReportFatalFailure+0x9:
00007ffe`d7b1b349 eb00            jmp     ntdll!RtlReportFatalFailure+0xb (00007ffe`d7b1b34b)
0:090> k
  *** Stack trace for last set context - .thread/.cxr resets it
 # Child-SP          RetAddr               Call Site
00 00000053`653fed10 00007ffe`d7b1b313     ntdll!RtlReportFatalFailure+0x9
01 00000053`653fed60 00007ffe`d7b23b9e     ntdll!RtlReportCriticalFailure+0x97
02 00000053`653fee50 00007ffe`d7b23eaa     ntdll!RtlpHeapHandleError+0x12
03 00000053`653fee80 00007ffe`d7abe109     ntdll!RtlpHpHeapHandleError+0x7a
04 00000053`653feeb0 00007ffe`d7acbb0e     ntdll!RtlpLogHeapFailure+0x45
05 00000053`653feee0 00007ffe`b093276f     ntdll!RtlFreeHeap+0x9d3ce
06 00000053`653fef80 00007ffe`b0943077     OraOps12!ssmem_free+0xf
07 00000053`653fefb0 00007ffe`b093cdd8     OraOps12!OpsMetFreeValCtx+0xd7
08 00000053`653fefe0 00007ffe`655e4374     OraOps12!OpsDacDispose+0x2b8
09 00000053`653ff060 00007ffe`655e31cf     0x00007ffe`655e4374
0a 00000053`653ff150 00007ffe`6a80969d     0x00007ffe`655e31cf
0b 00000053`653ff1f0 00007ffe`c4b96d06     0x00007ffe`6a80969d
0c 00000053`653ff220 00007ffe`c4c30e81     clr!FastCallFinalizeWorker+0x6
0d 00000053`653ff250 00007ffe`c4c30e09     clr!FastCallFinalize+0x55
0e 00000053`653ff2a0 00007ffe`c4c30d3a     clr!MethodTable::CallFinalizer+0xb5
0f 00000053`653ff2f0 00007ffe`c4c30bf5     clr!CallFinalizer+0x5e
10 00000053`653ff330 00007ffe`c4c304dc     clr!FinalizerThread::DoOneFinalization+0x95
11 00000053`653ff410 00007ffe`c4c31777     clr!FinalizerThread::FinalizeAllObjects+0xbf
12 00000053`653ff450 00007ffe`c4b97d01     clr!FinalizerThread::FinalizeAllObjects_Wrapper+0x18
13 00000053`653ff480 00007ffe`c4b97c70     clr!ManagedThreadBase_DispatchInner+0x39
14 00000053`653ff4c0 00007ffe`c4b97bad     clr!ManagedThreadBase_DispatchMiddle+0x6c
15 00000053`653ff5c0 00007ffe`c4b9ac34     clr!ManagedThreadBase_DispatchOuter+0x75
16 00000053`653ff650 00007ffe`c4bf5271     clr!ManagedThreadBase_DispatchInCorrectAD+0x15
17 00000053`653ff680 00007ffe`c4b9ac72     clr!Thread::DoADCallBack+0x109
18 00000053`653ff830 00007ffe`c4c3172a     clr!ManagedThreadBase_DispatchInner+0x82
19 00000053`653ff870 00007ffe`c4c304dc     clr!FinalizerThread::DoOneFinalization+0x1f1
1a 00000053`653ff950 00007ffe`c4c3062b     clr!FinalizerThread::FinalizeAllObjects+0xbf
1b 00000053`653ff990 00007ffe`c4b97d01     clr!FinalizerThread::FinalizerThreadWorker+0xbb
1c 00000053`653ff9d0 00007ffe`c4b97c70     clr!ManagedThreadBase_DispatchInner+0x39
1d 00000053`653ffa10 00007ffe`c4b97bad     clr!ManagedThreadBase_DispatchMiddle+0x6c
1e 00000053`653ffb10 00007ffe`c4cf4d4a     clr!ManagedThreadBase_DispatchOuter+0x75
1f 00000053`653ffba0 00007ffe`c4d5044f     clr!FinalizerThread::FinalizerThreadStart+0x126
20 00000053`653ffc40 00007ffe`d6157e94     clr!Thread::intermediateThreadProc+0x86
21 00000053`653ffd00 00007ffe`d7a87ad1     kernel32!BaseThreadInitThunk+0x14
22 00000053`653ffd30 00000000`00000000     ntdll!RtlUserThreadStart+0x21

0:090> !clrstack 
OS Thread Id: 0x5634 (90)
        Child SP               IP Call Site
00000053653ff0b8 00007ffed7abf0e4 [InlinedCallFrame: 00000053653ff0b8] Oracle.DataAccess.Client.OpsDac.Dispose(IntPtr, IntPtr, IntPtr, IntPtr ByRef, Oracle.DataAccess.Client.OpoMetValCtx*, Oracle.DataAccess.Client.OpoDacValCtx* ByRef, Oracle.DataAccess.Client.OpoSqlValCtx*, Int32, Int32)
00000053653ff0b8 00007ffe655e4374 [InlinedCallFrame: 00000053653ff0b8] Oracle.DataAccess.Client.OpsDac.Dispose(IntPtr, IntPtr, IntPtr, IntPtr ByRef, Oracle.DataAccess.Client.OpoMetValCtx*, Oracle.DataAccess.Client.OpoDacValCtx* ByRef, Oracle.DataAccess.Client.OpoSqlValCtx*, Int32, Int32)
00000053653ff060 00007ffe655e4374 DomainNeutralILStubClass.IL_STUB_PInvoke(IntPtr, IntPtr, IntPtr, IntPtr ByRef, Oracle.DataAccess.Client.OpoMetValCtx*, Oracle.DataAccess.Client.OpoDacValCtx* ByRef, Oracle.DataAccess.Client.OpoSqlValCtx*, Int32, Int32)
00000053653ff150 00007ffe655e31cf Oracle.DataAccess.Client.OracleDataReader.Dispose(Boolean)
00000053653ff1f0 00007ffe6a80969d Oracle.DataAccess.Client.OracleDataReader.Finalize()
00000053653ff608 00007ffec4b96d06 [DebuggerU2MCatchHandlerFrame: 00000053653ff608] 
00000053653ff788 00007ffec4b96d06 [ContextTransitionFrame: 00000053653ff788] 
00000053653ff8d0 00007ffec4b96d06 [GCFrame: 00000053653ff8d0] 
00000053653ffb58 00007ffec4b96d06 [DebuggerU2MCatchHandlerFrame: 00000053653ffb58] 

从调用栈来看,原来是
终结器线程
在调用
OracleDataReader.Dispose()
方法的时候抛的异常,这个结果还是挺意外的,也就是说这个问题不是用户代码造成的,真的是 Oracle 这个
OraOps12.dll
造成的。。。

接下来用
lm
观察下这个 dll 的详情信息,输出如下:


0:090> lmDvmOraOps12
Browse full module list
start             end                 module name
00007ffe`b0920000 00007ffe`b098c000   OraOps12 C (export symbols)       OraOps12.dll
    Loaded symbol image file: OraOps12.dll
    Image path: C:\ODAC\xxxx\OraOps12.dll
    Image name: OraOps12.dll
    Browse all global symbols  functions  data
    Timestamp:        Sat Sep 26 23:16:56 2015 (5606B6E8)
    CheckSum:         00000000
    ImageSize:        0006C000
    File version:     2.121.2.0
    Product version:  2.121.2.0
    File flags:       0 (Mask 3F)
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0409.04b0
    Information from resource tables:
        CompanyName:      Oracle Corporation
        ProductName:      Oracle Data Provider for .NET
        InternalName:     OraOps
        OriginalFilename: OraOps12.dll
        ProductVersion:   2.121.2.0 ODAC RELEASE 4
        FileVersion:      2.121.2.0
        FileDescription:  Oracle Provider Services
        LegalCopyright:   Copyright © 2014

虽然对 Oracle 不熟,但从
Timestamp: Sat Sep 26 23:16:56 2015
来看应该是一个比较老的 DLL 了,所以给到朋友的建议就是升级
OraOps12.dll

4. 是否有同行者

有时候直接让朋友升级dll有点缺少底气,最好就是找到一些同行者,经过一顿搜索,还真有同行者,又多了一份说服力,网址:
https://techcommunity.microsoft.com/t5/iis-support-blog/w3wp-exe-crash-exception-code-0xc0000005/ba-p/334351

三:总结

在百加dump的分析旅程中,碰到和 Oracle SDK 相关的也有
3+
起了,可能也许这些 SDK 在对接 .NET 上还不是特别稳健,大家在使用上尽量更新到最新版本吧,且用且珍惜!

图片名称



Mybatis高级特性能够帮助我们更加灵活地操作数据库,包括动态SQL、缓存机制、插件机制、自定义类型转换等。学习这些特性可以让我们更好地利用Mybatis,提高数据操作的效率和质量。

未来的道路由自己抉择,事业的高度由自己决定。

动态SQL

动态SQL中,Mybatis提供了多种标签来帮助我们构建动态的SQL语句,其中包括:

  • <if>
    :用于条件判断,可以动态添加WHERE语句的查询条件。
  • <where>
    :动态生成WHERE语句,可以过滤掉不需要的条件。
  • <set>
    :动态生成UPDATE语句,可以更新需要修改的字段。
  • <choose>
    :类似于Java中的switch语句,可以根据不同的条件生成不同的SQL语句。
  • <foreach>
    :用于循环遍历集合,可以将集合中的元素作为SQL语句的参数进行批量操作。

示例:

<update id="updateByPrimaryKeySelective" parameterType="com.youlai.mybatis.domain.SysUser">
        update sys_user
        <set>
                <if test="username != null">
                    username = #{username,jdbcType=VARCHAR},
                </if>
                <if test="nickname != null">
                    nickname = #{nickname,jdbcType=VARCHAR},
                </if>
                <if test="gender != null">
                    gender = #{gender,jdbcType=TINYINT},
                </if>
                <if test="password != null">
                    password = #{password,jdbcType=VARCHAR},
                </if>
                <if test="deptId != null">
                    dept_id = #{deptId,jdbcType=INTEGER},
                </if>
                <if test="avatar != null">
                    avatar = #{avatar,jdbcType=VARCHAR},
                </if>
                <if test="mobile != null">
                    mobile = #{mobile,jdbcType=VARCHAR},
                </if>
                <if test="status != null">
                    status = #{status,jdbcType=TINYINT},
                </if>
                <if test="email != null">
                    email = #{email,jdbcType=VARCHAR},
                </if>
                <if test="deleted != null">
                    deleted = #{deleted,jdbcType=TINYINT},
                </if>
                <if test="createTime != null">
                    create_time = #{createTime,jdbcType=TIMESTAMP},
                </if>
                <if test="updateTime != null">
                    update_time = #{updateTime,jdbcType=TIMESTAMP},
                </if>
        </set>
        where   id = #{id,jdbcType=INTEGER} 
    </update>

动态SQL的优化技巧:

  1. 尽量使用
    <where>
    标签生成WHERE语句,可以避免出现多余的AND或OR关键字。
  2. 使用
    <foreach>
    标签批量操作时,尽量使用batch模式,而不是简单的循环逐一执行。
  3. 对于常用的动态SQL语句,可以使用Mybatis提供的缓存机制进行优化。
  4. 尽量避免在动态SQL中使用
    select *
    语句,而是明确指定需要查询的字段。
  5. 在动态SQL中尽量使用预编译语句,可以提高SQL语句的执行效率。
让自己不断进步,让职业越来越优秀。

缓存机制

  • 一级缓存和二级缓存的区别
  • 一级缓存是Mybatis默认开启的缓存,它是在同一个SqlSession内部共享的缓存,它可以通过查询语句的唯一标识符(id)和查询参数作为key进行缓存,可以有效地避免重复查询。一级缓存的生命周期与SqlSession相同,当SqlSession关闭时,它的缓存也会被清空。
  • 二级缓存是Mybatis的全局缓存,它可以被多个SqlSession共享,适用于需要跨SqlSession共享数据的场景。它的存储方式是将数据放在一个HashMap中,key是查询语句的唯一标识符和查询参数的组合,value是查询到的结果。二级缓存的生命周期与整个应用程序相同,它可以在应用程序的多个SqlSession之间共享查询结果,但也由于这个原因,它的数据一旦被修改,就需要手动刷新缓存,否则会导致数据的不一致。
  • 缓存的配置和使用方式

配置方式:


mybatis:
  configuration:
    cache-enabled: true   #开启二级缓存(默认开启)
    local-cache-scope: statement #关闭一级缓存(默认开启)
#   local-cache-scope: session   #开启一级缓存(默认开启)

使用方式:

<mapper namespace="com.youlai.mybatis.mapper.SysUserMapper">
    <cache type="com.youlai.mybatis.service.MyCustomCache"/
</mapper>

自定义缓存实现,这里采用本地存储,分布式建议用redis

@Component
@Slf4j
public class MyCustomCache implements Cache, Serializable {

    private String id;
    private Map<Object, Object> cache = new ConcurrentHashMap<>();

    public MyCustomCache() {
    }

    public MyCustomCache(String id) {
        this.id = id;
    }

    @Override
    public String getId() {
        log.info("获取缓存标识:{}",id);
        return id;
    }

    @Override
    public void putObject(Object key, Object value) {
        log.info("添加缓存key:{},value:{}",key,value);
        cache.put(key, value);
    }

    @Override
    public Object getObject(Object key) {
        log.info("获取缓存key:{}",key);
        return cache.get(key);
    }

    @Override
    public Object removeObject(Object key) {
        log.info("删除缓存key:{}",key);
        return cache.remove(key);
    }

    @Override
    public void clear() {
        log.info("清空缓存");
        cache.clear();
    }

    @Override
    public int getSize() {
        log.info("获取缓存数量:{}",cache.size());
        return cache.size();
    }

    @Override
    public ReadWriteLock getReadWriteLock() {
        log.info("拿锁");
        ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock(true);
        return readWriteLock;
    }

    private void writeObject(ObjectOutputStream out) throws IOException {
        out.writeObject(cache);
    }

    private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
        cache = (Map<Object, Object>) in.readObject();
    }

}
做自己喜欢的事情,成为自己想成为的人。

插件机制

Mybatis插件可以在执行过程中拦截指定的方法,对其进行增强或者修改,原理是使用JDK动态代理机制,对Mybatis的接口进行代理,从而实现对SQL执行过程的拦截和修改,可以实现一些比较复杂的功能,例如:

  • 对SQL语句进行拦截和修改,实现动态SQL的功能。
  • 统计SQL执行的时间,方便对性能进行优化。
  • 实现通用的分页查询功能。
  • 对查询结果进行加密或解密。

自定义插件的步骤:

  1. 实现Interceptor接口,重写intercept方法。
  2. 在intercept方法中编写拦截逻辑,对需要拦截的方法进行增强或修改。
  3. 在plugin方法中,将拦截器实例化,并返回代理对象。
  4. 在Mybatis配置中添加插件。

以下是一个统计SQL执行时间示例:

@Intercepts({
        @Signature(type = StatementHandler.class, method = "query", args = {Statement.class, ResultHandler.class})
})
@Slf4j
public class MybatisPlugin implements Interceptor {
    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        // TODO: 拦截逻辑
        log.info("进入拦截器");
        long startTime = System.currentTimeMillis();
        Object result = invocation.proceed();
        long endTime = System.currentTimeMillis();
        long sqlTime = endTime - startTime;
        StatementHandler statementHandler = (StatementHandler)invocation.getTarget();
        String sql = statementHandler.getBoundSql().getSql();
        ParameterHandler parameterHandler = statementHandler.getParameterHandler();
        log.info("执行sql:{},参数:{},花费了{}毫秒",sql,parameterHandler.getParameterObject().toString(),sqlTime);
        return result;
    }

    @Override
    public Object plugin(Object target) {
        log.info("生成代理对象");
        return Interceptor.super.plugin(target);
    }

    @Override
    public void setProperties(Properties properties) {
        log.info("设置插件属性");
        Interceptor.super.setProperties(properties);
    }
}

添加插件

@Component
public class MySqlSessionFactoryBeanCustomizer implements SqlSessionFactoryBeanCustomizer{
    @Override
    public void customize(SqlSessionFactoryBean factoryBean) {
        //注册插件
        factoryBean.setPlugins(new MybatisPlugin());
    }

}
保持热情与好奇心,不断追求进步和创新。

自定义类型转换

Mybatis中的类型转换指的是Java类型和数据库类型之间的转换。在Mybatis中,我们可以使用TypeHandler来实现自定义的类型转换。

自定义TypeHandler的步骤如下:

  1. 创建一个类,实现org.apache.ibatis.type.TypeHandler接口。
  2. 在类上使用@MappedJdbcTypes注解指定要转换的JDBC类型。
  3. 在类上使用@MappedTypes注解指定要转换的Java类型。
  4. 重写TypeHandler接口中的方法,实现自定义的类型转换逻辑。

示例:

@MappedJdbcTypes(JdbcType.VARCHAR)
@MappedTypes(String.class)
@Slf4j
public class MyStringTypeHandler implements TypeHandler<String> {

    @Override
    public void setParameter(PreparedStatement ps, int i, String parameter, JdbcType jdbcType) throws SQLException {
        log.info("将Java类型的参数转换为JDBC类型的参数,并设置到PreparedStatement中");
        ps.setString(i, parameter);
    }

    @Override
    public String getResult(ResultSet rs, String columnName) throws SQLException {
        log.info("通过列名{}获取数据,将JDBC类型中的结果转换为java类型",columnName);
        return rs.getString(columnName);
    }

    @Override
    public String getResult(ResultSet rs, int columnIndex) throws SQLException {
        log.info("通过索引获取数据,将JDBC类型中的结果转换为java类型");
        return rs.getString(columnIndex);
    }

    @Override
    public String getResult(CallableStatement cs, int columnIndex) throws SQLException {
        log.info("通过索引获取数据,将JDBC类型中的结果转换为java类型");
        return cs.getString(columnIndex);
    }
}

注册

@Component
public class MySqlSessionFactoryBeanCustomizer implements ConfigurationCustomizer {

    @Override
    public void customize(Configuration configuration) {
        configuration.getTypeHandlerRegistry().register(String.class,new MyStringTypeHandler());
    }
}

以上示例中,我们自定义了一个将Java String类型转换为JDBC VARCHAR类型的TypeHandler。

完整代码:
https://gitee.com/youlaiorg/youlai-learning.git

总结

本文介绍了Mybatis的高级特性,包括动态SQL的优化技巧、缓存机制、插件机制和自定义类型转换。动态SQL的优化技巧包括使用
<where>
标签生成WHERE语句、使用
<foreach>
标签批量操作时尽量使用batch模式等。缓存机制包括一级缓存和二级缓存,可以通过配置文件进行开启或关闭。插件机制可以在Mybatis的执行过程中拦截指定的方法,对其进行增强或者修改。自定义类型转换可以将Java类型和数据库类型之间进行转换。

不断学习和成长,实现自我价值和职业发展的双赢。

内存重叠是指在内存中存在两个或多个区域,它们的地址范围有交叉部分。在 C++ 中,内存重叠可能会导致程序出现不可预期的行为,因此我们需要了解它的原因和如何避免。

内存重叠的原因

内存重叠的主要原因是指针的使用。当我们使用指针访问内存时,如果指针指向的内存区域与另一个区域有交叉部分,就会产生内存重叠。

如下图,内存拷贝的两种情况:

img

第一种情况下,拷贝重叠的区域不会出现问题,内容均可以正确地被拷贝。

第二种情况下,问题出现在右边的两个字节,这两个字节的原来的内容首先就被覆盖了,而且没有保存。所以接下来拷贝的时候,拷贝的是已经被覆盖的内容,显然这是有问题的。

举个代码例子,下面的代码片段就会导致内存重叠:

char str[] = "Hello World";
char* p = str + 1;
memcpy(p, str, 11);

在上面的代码中,我们定义了一个字符数组
str
,并使用指针
p
指向
str
中的第二个字符。接着,我们使用
memcpy
函数将
str
中的 11 个字符复制到了
p
指向的区域。由于
p
指向的区域与
str
有交叉部分,因此就产生了内存重叠。因为
memcpy
是直接按位复制拷贝,代码如下,所以会遇到情况二,拷贝的是已经被覆盖的内容。

void *memcpy(void *dest, const void *src, size_t count)
{
	char *tmp = dest;
	const char *s = src;

	while (count--)
		*tmp++ = *s++;
	return dest;
}

如何避免内存重叠

为了避免内存重叠,我们需要注意以下几点:

  • 尽量避免使用指针,尤其是指针运算和类型转换;
  • 在使用指针时,确保指针指向的内存区域与其他区域没有交叉部分;
  • 使用安全的内存操作函数,如
    memcpy_s

    memmove
    等,这些函数可以确保在复制内存时不会产生内存重叠。


memmove
是怎么避免内存重叠的影响呢,我们看看
memmove
的代码:

void *memmove(void *dest, const void *src, size_t n)
{
    char *d = dest;
    const char *s = src;

    if (d < s) {
        while (n--)
            *d++ = *s++;
    } else {
        // 采用倒序拷贝
        char *lasts = (char *)s + (n - 1);
        char *lastd = d + (n - 1);
        while (n--)
            *lastd-- = *lasts--;
    }

    return dest;
}

memmove
判断如果
dest

src
的时候(也就是前面图片的情况2),采用倒序拷贝,避免了内容被覆盖导致拷贝不完整的问题。

其原理图如下:

img

memcpy 与 strcpy 都没有内存重叠的问题,实际可以根据需要使用 memmove 。

总结

本文介绍了 C++ 中的内存重叠问题,指出了指针的使用是内存重叠的主要原因,并提供了避免内存重叠的方法,如尽量避免使用指针,确保指针指向的内存区域与其他区域没有交叉部分,使用安全的内存操作函数等。此外,还介绍了
memmove
函数如何避免内存重叠的影响。