这里的问题是你的IDEA内置的ECJ版本太高了
把图中红框部分的内容替换一个合适的版本jar包就行了。这个jar除了可以单独下载,在tomcat / lib 目录下也存在
没有足够的数据
(゚∀゚ )
暂时没有任何数据
Vitamin 回答了问题 · 2020-01-14
这里的问题是你的IDEA内置的ECJ版本太高了
把图中红框部分的内容替换一个合适的版本jar包就行了。这个jar除了可以单独下载,在tomcat / lib 目录下也存在
这里的问题是你的IDEA内置的ECJ版本太高了把图中红框部分的内容替换一个合适的版本jar包就行了。这个jar除了可以单独下载,在tomcat / lib 目录下也存在
关注 2 回答 1
Vitamin 关注了用户 · 2019-05-20
欢迎关注马蜂窝技术,我们将定期分享马蜂窝技术团队先进的技术实践,期待您与马蜂窝一起见证技术对行业的赋能和改变。
欢迎关注马蜂窝技术,我们将定期分享马蜂窝技术团队先进的技术实践,期待您与马蜂窝一起见证技术对行业的赋能和改变。
关注 1671
Vitamin 发布了文章 · 2019-03-26
git mv [文件名] [新文件名]
git rm [文件名]
git commit --amend
git rebase -i [要修改Commit的父加密串]
例如:我的变更中发现c928292
中的Message书写错误
git rebase -i [要修改Commit的父加密串]
例如:我需要将最近2次对index.html的修改进行合并
这里主要是对rebase的操作,无论是修改commit的Message,还是合并连续和非连续的Commit,都是可以使用rebase命令来进行操作的,其中的不同在于要在对话框中执行的命令,具体的命令可以通过对话框中的信息可以查看
git diff -- [路径1] [路径2] [路径3....]
git diff HEAD -- [路径1] [路径2] [路径3....]
git diff --cached HEAD -- [路径1] [路径2] [路径3....]
git cat-file -p [某次Commit的加密串]
例如:我想查看合并后index.htm的文件内容
任何一次commit信息中都会包含一个树装结构来存储此次Commit中文件的状态,其中blob
类型就是具体的文件
git reset HEAD
此操作会将提交到暂存区的改变撤销到工作区
git checkout -- [路径1] [路径2] [路径3....]
git reset --hard HEAD
git reset --hard [具体的commit的加密串]
git stash
#记录会以栈的方式进行存储
当我们处理完新任务后,继续以前的开发需要执行以下命令
git stash pop 或 git stash apply
#二者的主要区别就是:后者仍然会保留存储的记录,以便多次使用
git clone [当前库所在的路径] [目标备份库所在的路径]
查看原文例如:我需要将最近2次对index.html的修改进行合并这里主要是对rebase的操作,无论是修改commit的Message,还是合并连续和非连续的Commit,都是可以使用rebase命令来进行操作的,其中的不同在于要在对话框中执行的命令,具体的命令可以通过对话框中的信息可以查看
赞 0 收藏 0 评论 0
Vitamin 发布了文章 · 2019-03-22
/// 随机获取指定范围内N个不重复数字 /// </summary> /// <param name="min">指定范围最小值</param> /// <param name="max">指定范围最大值</param> /// <param name="num">不重复数字的个数</param> /// <returns></returns> private int[] NonRepeatingRandomNumbers(int min, int max, int num) { int len = max - min + 1; if (min > max || len < 0 || num < 0 || num > len) { throw new Exception("输入参数错误"); } int[] numbers = new int[len]; for (int i = min; i <= max; i++) { numbers[i - min] = i; } int[] result = new int[num]; for (int i = 0; i < num; i++) { Random random = new Random(); int index = random.Next(0, --len); result[i] = numbers[index]; numbers[index] = numbers[len]; } return result; }
代码解读
1. 数据源(numbers):存储用户输入最小值(包含)和最大值(包含)之间的连续自然数
2. 目标数组(result):存储最终需要返回的不重复数字
3. 数据源数组长度(len):通过计算得出数据源的数组长度,以便初始化数组,存储数据源
4. 核心循环:
4.1 从[0,len-1]范围内随机获取下标,并取值放到目标数组内,同时将获取到的元素替换为len-1位置的元素;
4.2 然后从[0,len-2]范围内随机获取下标,并取值放置到目标数组中,同时将获取到的元素替换为len-2位置的元素;
4.3 以此类推直到满足目标数组元素的个数为止;
分析
算法的时间复杂度为O(N)
查看原文{代码...} 代码解读 {代码...} 分析 算法的时间复杂度为O(N)
赞 0 收藏 0 评论 0
Vitamin 收藏了文章 · 2019-03-13
同源策略的分类:
DOM
进行操作;如不同域名的 iframe 是限制互相访问。不受同源策略限制:
<script data-original="..."></script>,<img>,<link>,<iframe>
等xss
的研究了,因为你的网站将不是你的网站,而是大家的,谁都可以写个代码操作你的网站界面如果没有XMLHttpRequest 同源策略,那么就可以很轻易的进行CSRF(跨站请求伪造)攻击:
a.com
,cookie中添加了用户标识。b.com
,执行了页面中的恶意 AJAX 请求代码。b.com
向 a.com
发起 AJAX HTTP 请求,请求会默认把 a.com
对应cookie
也同时发送过去。a.com
从发送的 cookie 中提取用户标识,验证用户无误,response 中返回请求数据;数据就泄露了。而且由于Ajax在后台执行,这一过程用户是无法感知的。JSONP 跨域:借鉴于 script 标签不受浏览器同源策略的影响,允许跨域引用资源;因此可以通过动态创建 script 标签,然后利用 src 属性进行跨域;
Access-Control-Allow-Origin:*|[或具体的域名]
就好了;app.use(async(ctx,next) => {
ctx.set({
"Access-Control-Allow-Origin": "http://localhost:8088"
})
OPTIONS
请求:浏览器发送跨域请求判断方式:
请求方法是如下之一:
所有的Header都只包含如下列表中(没有自定义header):
Origin:请求的源域信息
Access-Control-Request-Method:接下来的请求类型,如POST、GET等
Access-Control-Request-Headers:接下来的请求中包含的用户显式设置的Header列表
Access-Control-Allow-Origin:允许跨域的Origin列表
Access-Control-Allow-Methods:允许跨域的方法列表
Access-Control-Allow-Headers:允许跨域的Header列表,防止遗漏Header,因此建议没有特殊需求的情况下设置为*
Access-Control-Expose-Headers:允许暴露给JavaScript代码的Header列表
Access-Control-Max-Age:最大的浏览器预检请求缓存时间,单位为s
const cors = (origin) => {
return async (ctx, next) => {
ctx.set({
"Access-Control-Allow-Origin": origin, //允许的源
})
// 预检请求
if (ctx.request.method == "OPTIONS") {
ctx.set({
'Access-Control-Allow-Methods': 'OPTIONS,HEAD,DELETE,GET,PUT,POST', //支持跨域的方法
'Access-Control-Allow-Headers': '*', //允许的头
'Access-Control-Max-Age':10000, // 预检请求缓存时间
// 如果服务器设置Access-Control-Allow-Credentials为true,那么就不能再设置Access-Control-Allow-Origin为*,必须用具体的域名
'Access-Control-Allow-Credentials':true // 跨域请求携带身份信息(Credential,例如Cookie或者HTTP认证信息)
});
ctx.send(null, '预检请求')
} else {
// 真实请求
await next()
}
}
}
export default cors
cookie:
问题:
set-cookie
但是,浏览器cookie并没有相应的cookie)决解:
axios.defaults.withCredentials = true
Access-Control-Allow-Credentials=true
允许跨域请求携带 Cookie“积跬步、行千里”—— 持续更新中~,喜欢的话留下个赞和关注哦!查看原文
了解下同源策略 源(origin)*:就是协议、域名和端口号; 同源: 就是源相同,即协议、域名和端口完全相同; 同源策略:同源策略是浏览器的一个安全功能,不同源的客户端脚本在没有明确授权的情况下,不能读写对方资源; 同源策略的分类: DOM 同源策略:即针对于DO...
Vitamin 收藏了文章 · 2019-03-13
同源策略的分类:
DOM
进行操作;如不同域名的 iframe 是限制互相访问。不受同源策略限制:
<script data-original="..."></script>,<img>,<link>,<iframe>
等xss
的研究了,因为你的网站将不是你的网站,而是大家的,谁都可以写个代码操作你的网站界面如果没有XMLHttpRequest 同源策略,那么就可以很轻易的进行CSRF(跨站请求伪造)攻击:
a.com
,cookie中添加了用户标识。b.com
,执行了页面中的恶意 AJAX 请求代码。b.com
向 a.com
发起 AJAX HTTP 请求,请求会默认把 a.com
对应cookie
也同时发送过去。a.com
从发送的 cookie 中提取用户标识,验证用户无误,response 中返回请求数据;数据就泄露了。而且由于Ajax在后台执行,这一过程用户是无法感知的。JSONP 跨域:借鉴于 script 标签不受浏览器同源策略的影响,允许跨域引用资源;因此可以通过动态创建 script 标签,然后利用 src 属性进行跨域;
Access-Control-Allow-Origin:*|[或具体的域名]
就好了;app.use(async(ctx,next) => {
ctx.set({
"Access-Control-Allow-Origin": "http://localhost:8088"
})
OPTIONS
请求:浏览器发送跨域请求判断方式:
请求方法是如下之一:
所有的Header都只包含如下列表中(没有自定义header):
Origin:请求的源域信息
Access-Control-Request-Method:接下来的请求类型,如POST、GET等
Access-Control-Request-Headers:接下来的请求中包含的用户显式设置的Header列表
Access-Control-Allow-Origin:允许跨域的Origin列表
Access-Control-Allow-Methods:允许跨域的方法列表
Access-Control-Allow-Headers:允许跨域的Header列表,防止遗漏Header,因此建议没有特殊需求的情况下设置为*
Access-Control-Expose-Headers:允许暴露给JavaScript代码的Header列表
Access-Control-Max-Age:最大的浏览器预检请求缓存时间,单位为s
const cors = (origin) => {
return async (ctx, next) => {
ctx.set({
"Access-Control-Allow-Origin": origin, //允许的源
})
// 预检请求
if (ctx.request.method == "OPTIONS") {
ctx.set({
'Access-Control-Allow-Methods': 'OPTIONS,HEAD,DELETE,GET,PUT,POST', //支持跨域的方法
'Access-Control-Allow-Headers': '*', //允许的头
'Access-Control-Max-Age':10000, // 预检请求缓存时间
// 如果服务器设置Access-Control-Allow-Credentials为true,那么就不能再设置Access-Control-Allow-Origin为*,必须用具体的域名
'Access-Control-Allow-Credentials':true // 跨域请求携带身份信息(Credential,例如Cookie或者HTTP认证信息)
});
ctx.send(null, '预检请求')
} else {
// 真实请求
await next()
}
}
}
export default cors
cookie:
问题:
set-cookie
但是,浏览器cookie并没有相应的cookie)决解:
axios.defaults.withCredentials = true
Access-Control-Allow-Credentials=true
允许跨域请求携带 Cookie“积跬步、行千里”—— 持续更新中~,喜欢的话留下个赞和关注哦!查看原文
了解下同源策略 源(origin)*:就是协议、域名和端口号; 同源: 就是源相同,即协议、域名和端口完全相同; 同源策略:同源策略是浏览器的一个安全功能,不同源的客户端脚本在没有明确授权的情况下,不能读写对方资源; 同源策略的分类: DOM 同源策略:即针对于DO...
Vitamin 赞了文章 · 2019-03-13
同源策略的分类:
DOM
进行操作;如不同域名的 iframe 是限制互相访问。不受同源策略限制:
<script data-original="..."></script>,<img>,<link>,<iframe>
等xss
的研究了,因为你的网站将不是你的网站,而是大家的,谁都可以写个代码操作你的网站界面如果没有XMLHttpRequest 同源策略,那么就可以很轻易的进行CSRF(跨站请求伪造)攻击:
a.com
,cookie中添加了用户标识。b.com
,执行了页面中的恶意 AJAX 请求代码。b.com
向 a.com
发起 AJAX HTTP 请求,请求会默认把 a.com
对应cookie
也同时发送过去。a.com
从发送的 cookie 中提取用户标识,验证用户无误,response 中返回请求数据;数据就泄露了。而且由于Ajax在后台执行,这一过程用户是无法感知的。JSONP 跨域:借鉴于 script 标签不受浏览器同源策略的影响,允许跨域引用资源;因此可以通过动态创建 script 标签,然后利用 src 属性进行跨域;
Access-Control-Allow-Origin:*|[或具体的域名]
就好了;app.use(async(ctx,next) => {
ctx.set({
"Access-Control-Allow-Origin": "http://localhost:8088"
})
OPTIONS
请求:浏览器发送跨域请求判断方式:
请求方法是如下之一:
所有的Header都只包含如下列表中(没有自定义header):
Origin:请求的源域信息
Access-Control-Request-Method:接下来的请求类型,如POST、GET等
Access-Control-Request-Headers:接下来的请求中包含的用户显式设置的Header列表
Access-Control-Allow-Origin:允许跨域的Origin列表
Access-Control-Allow-Methods:允许跨域的方法列表
Access-Control-Allow-Headers:允许跨域的Header列表,防止遗漏Header,因此建议没有特殊需求的情况下设置为*
Access-Control-Expose-Headers:允许暴露给JavaScript代码的Header列表
Access-Control-Max-Age:最大的浏览器预检请求缓存时间,单位为s
const cors = (origin) => {
return async (ctx, next) => {
ctx.set({
"Access-Control-Allow-Origin": origin, //允许的源
})
// 预检请求
if (ctx.request.method == "OPTIONS") {
ctx.set({
'Access-Control-Allow-Methods': 'OPTIONS,HEAD,DELETE,GET,PUT,POST', //支持跨域的方法
'Access-Control-Allow-Headers': '*', //允许的头
'Access-Control-Max-Age':10000, // 预检请求缓存时间
// 如果服务器设置Access-Control-Allow-Credentials为true,那么就不能再设置Access-Control-Allow-Origin为*,必须用具体的域名
'Access-Control-Allow-Credentials':true // 跨域请求携带身份信息(Credential,例如Cookie或者HTTP认证信息)
});
ctx.send(null, '预检请求')
} else {
// 真实请求
await next()
}
}
}
export default cors
cookie:
问题:
set-cookie
但是,浏览器cookie并没有相应的cookie)决解:
axios.defaults.withCredentials = true
Access-Control-Allow-Credentials=true
允许跨域请求携带 Cookie“积跬步、行千里”—— 持续更新中~,喜欢的话留下个赞和关注哦!查看原文
了解下同源策略 源(origin)*:就是协议、域名和端口号; 同源: 就是源相同,即协议、域名和端口完全相同; 同源策略:同源策略是浏览器的一个安全功能,不同源的客户端脚本在没有明确授权的情况下,不能读写对方资源; 同源策略的分类: DOM 同源策略:即针对于DO...
赞 127 收藏 102 评论 3
Vitamin 赞了文章 · 2018-12-27
原文地址:在 Go 中恰到好处的内存对齐
type Part1 struct {
a bool
b int32
c int8
d int64
e byte
}
在开始之前,希望你计算一下 Part1
共占用的大小是多少呢?
func main() {
fmt.Printf("bool size: %d\n", unsafe.Sizeof(bool(true)))
fmt.Printf("int32 size: %d\n", unsafe.Sizeof(int32(0)))
fmt.Printf("int8 size: %d\n", unsafe.Sizeof(int8(0)))
fmt.Printf("int64 size: %d\n", unsafe.Sizeof(int64(0)))
fmt.Printf("byte size: %d\n", unsafe.Sizeof(byte(0)))
fmt.Printf("string size: %d\n", unsafe.Sizeof("EDDYCJY"))
}
输出结果:
bool size: 1
int32 size: 4
int8 size: 1
int64 size: 8
byte size: 1
string size: 16
这么一算,Part1
这一个结构体的占用内存大小为 1+4+1+8+1 = 15 个字节。相信有的小伙伴是这么算的,看上去也没什么毛病
真实情况是怎么样的呢?我们实际调用看看,如下:
type Part1 struct {
a bool
b int32
c int8
d int64
e byte
}
func main() {
part1 := Part1{}
fmt.Printf("part1 size: %d, align: %d\n", unsafe.Sizeof(part1), unsafe.Alignof(part1))
}
输出结果:
part1 size: 32, align: 8
最终输出为占用 32 个字节。这与前面所预期的结果完全不一样。这充分地说明了先前的计算方式是错误的。为什么呢?
在这里要提到 “内存对齐” 这一概念,才能够用正确的姿势去计算,接下来我们详细的讲讲它是什么
有的小伙伴可能会认为内存读取,就是一个简单的字节数组摆放
上图表示一个坑一个萝卜的内存读取方式。但实际上 CPU 并不会以一个一个字节去读取和写入内存。相反 CPU 读取内存是一块一块读取的,块的大小可以为 2、4、6、8、16 字节等大小。块大小我们称其为内存访问粒度。如下图:
在样例中,假设访问粒度为 4。 CPU 是以每 4 个字节大小的访问粒度去读取和写入内存的。这才是正确的姿势
另外作为一个工程师,你也很有必要学习这块知识点哦 :)
在上图中,假设从 Index 1 开始读取,将会出现很崩溃的问题。因为它的内存访问边界是不对齐的。因此 CPU 会做一些额外的处理工作。如下:
从上述流程可得出,不做 “内存对齐” 是一件有点 "麻烦" 的事。因为它会增加许多耗费时间的动作
而假设做了内存对齐,从 Index 0 开始读取 4 个字节,只需要读取一次,也不需要额外的运算。这显然高效很多,是标准的空间换时间做法
在不同平台上的编译器都有自己默认的 “对齐系数”,可通过预编译命令 #pragma pack(n)
进行变更,n 就是代指 “对齐系数”。一般来讲,我们常用的平台的系数如下:
另外要注意,不同硬件平台占用的大小和对齐值都可能是不一样的。因此本文的值不是唯一的,调试的时候需按本机的实际情况考虑
func main() {
fmt.Printf("bool align: %d\n", unsafe.Alignof(bool(true)))
fmt.Printf("int32 align: %d\n", unsafe.Alignof(int32(0)))
fmt.Printf("int8 align: %d\n", unsafe.Alignof(int8(0)))
fmt.Printf("int64 align: %d\n", unsafe.Alignof(int64(0)))
fmt.Printf("byte align: %d\n", unsafe.Alignof(byte(0)))
fmt.Printf("string align: %d\n", unsafe.Alignof("EDDYCJY"))
fmt.Printf("map align: %d\n", unsafe.Alignof(map[string]string{}))
}
输出结果:
bool align: 1
int32 align: 4
int8 align: 1
int64 align: 8
byte align: 1
string align: 8
map align: 8
在 Go 中可以调用 unsafe.Alignof
来返回相应类型的对齐系数。通过观察输出结果,可得知基本都是 2^n
,最大也不会超过 8。这是因为我手提(64 位)编译器默认对齐系数是 8,因此最大值不会超过这个数
在上小节中,提到了结构体中的成员变量要做字节对齐。那么想当然身为最终结果的结构体,也是需要做字节对齐的
#pragma pack(n)
)或当前成员变量类型的长度(unsafe.Sizeof
),取最小值作为当前类型的对齐值。其偏移量必须为对齐值的整数倍#pragma pack(n)
)或结构体的所有成员变量类型中的最大长度,取最大数的最小整数倍作为对齐值#pragma pack(n)
)超过结构体内成员变量的类型最大长度时,默认对齐长度是没有任何意义的接下来我们一起分析一下,“它” 到底经历了些什么,影响了 “预期” 结果
成员变量 | 类型 | 偏移量 | 自身占用 |
---|---|---|---|
a | bool | 0 | 1 |
字节对齐 | 无 | 1 | 3 |
b | int32 | 4 | 4 |
c | int8 | 8 | 1 |
字节对齐 | 无 | 9 | 7 |
d | int64 | 16 | 8 |
e | byte | 24 | 1 |
字节对齐 | 无 | 25 | 7 |
总占用大小 | - | - | 32 |
第一个成员 a
第二个成员 b
第三个成员 c
第四个成员 d
第五个成员 e
在每个成员变量进行对齐后,根据规则 2,整个结构体本身也要进行字节对齐,因为可发现它可能并不是 2^n
,不是偶数倍。显然不符合对齐的规则
根据规则 2,可得出对齐值为 8。现在的偏移量为 25,不是 8 的整倍数。因此确定偏移量为 32。对结构体进行对齐
Part1 内存布局:axxx|bbbb|cxxx|xxxx|dddd|dddd|exxx|xxxx
通过本节的分析,可得知先前的 “推算” 为什么错误?
是因为实际内存管理并非 “一个萝卜一个坑” 的思想。而是一块一块。通过空间换时间(效率)的思想来完成这块读取、写入。另外也需要兼顾不同平台的内存操作情况
在上一小节,可得知根据成员变量的类型不同,其结构体的内存会产生对齐等动作。那假设字段顺序不同,会不会有什么变化呢?我们一起来试试吧 :-)
type Part1 struct {
a bool
b int32
c int8
d int64
e byte
}
type Part2 struct {
e byte
c int8
a bool
b int32
d int64
}
func main() {
part1 := Part1{}
part2 := Part2{}
fmt.Printf("part1 size: %d, align: %d\n", unsafe.Sizeof(part1), unsafe.Alignof(part1))
fmt.Printf("part2 size: %d, align: %d\n", unsafe.Sizeof(part2), unsafe.Alignof(part2))
}
输出结果:
part1 size: 32, align: 8
part2 size: 16, align: 8
通过结果可以惊喜的发现,只是 “简单” 对成员变量的字段顺序进行改变,就改变了结构体占用大小
接下来我们一起剖析一下 Part2
,看看它的内部到底和上一位之间有什么区别,才导致了这样的结果?
成员变量 | 类型 | 偏移量 | 自身占用 |
---|---|---|---|
e | byte | 0 | 1 |
c | int8 | 1 | 1 |
a | bool | 2 | 1 |
字节对齐 | 无 | 3 | 1 |
b | int32 | 4 | 4 |
d | int64 | 8 | 8 |
总占用大小 | - | - | 16 |
第一个成员 e
第二个成员 c
第三个成员 a
第四个成员 b
第五个成员 d
符合规则 2,不需要额外对齐
Part2 内存布局:ecax|bbbb|dddd|dddd
通过对比 Part1
和 Part2
的内存布局,你会发现两者有很大的不同。如下:
仔细一看,Part1
存在许多 Padding。显然它占据了不少空间,那么 Padding 是怎么出现的呢?
通过本文的介绍,可得知是由于不同类型导致需要进行字节对齐,以此保证内存的访问边界
那么也不难理解,为什么调整结构体内成员变量的字段顺序就能达到缩小结构体占用大小的疑问了,是因为巧妙地减少了 Padding 的存在。让它们更 “紧凑” 了。这一点对于加深 Go 的内存布局印象和大对象的优化非常有帮
当然了,没什么特殊问题,你可以不关注这一块。但你要知道这块知识点 😄
原文地址:在 Go 中恰到好处的内存对齐 问题 {代码...} 在开始之前,希望你计算一下 Part1 共占用的大小是多少呢? {代码...} 输出结果: {代码...} 这么一算,Part1 这一个结构体的占用内存大小为 1+4+1+8+1 = 15 个字节。相信有的小伙伴是这么算的,看上去也没什么...
赞 77 收藏 39 评论 4
查看全部 个人动态 →
(゚∀゚ )
暂时没有
注册于 2018-07-26
个人主页被 389 人浏览
推荐关注