UTF8 中文占多少字节问题
看了网上一堆人扯淡的人云亦云,有的说是3字节,有的说是2字节-4字节,有的说是4字节。
本来昨晚帮同事解决中文乱码问题,对这个提起了兴趣,查了下wiki百科里面unicode编码表。
只要在CJK的部分就可能有汉字,为此专门随机挑选了几个CJK下的表看了下,大多数都是3字节的,但是有存在4字节的情况。
不信邪的小伙子们可以拿下面这个表去测试下,哈

也就是说按照目前的情况来看
> 有CJK的可能就有汉字,所以不局限于0X4E00到0x9FA5,也不要绝对的认为0X9FA5就是尽头,0X4E00就是起点。
2018-12-27 02:25
JBoss 中文乱码
新来的同事在搞开放平台,一个乱码问题整了很久,主要是对JBoss的配置不是很熟悉,我以前遇到过这种情况,就帮着解决了下。
第三方应用调用开放平台的接口,GET请求,参数直接在URL上,其中参数存在中文,默认的设置会乱码。
JBoss的配置和tomcat类似。
```
<Connector port="8080" address="${jboss.bind.address}"
maxThreads="1000" maxHttpHeaderSize="8192"
emptySessionPath="true" protocol="HTTP/1.1"
enableLookups="false" redirectPort="8443" acceptCount="500"
connectionTimeout="20000" disableUploadTimeout="true" />
```
在尾部添加
```
URIEncoding="UTF-8"
```
变成了:
```
<Connector port="8080" a...
2018-12-26 13:34
JVM 参数调优
看zabbix报错日志的时候,发现集群环境的很多服务的堆内存有异常
具体表现如下:
某个时间某机器出现大量的RPC调用超时,持续大致一分钟左右,偶尔还会出现机器的拉起脚本判定服务失联,kill掉之后重新启动。
这些现象都伴随着堆内存占用非常高,且查看gc日志发现此时进行了fullGC,时间长达56S的fullGC!
在没进行fullGC的前二十四个小时内,堆内存占用是稳步缓缓上升的,没有明显的下降趋势
初次怀疑内存泄露或者是垃圾回收导致的
```
jcmd pid GC.class_histgram
```
发现没有什么异常对象
```
1: 127986 16991200 [C
2: 13598 9982736 [B
3: 124786 2994864 java.lang.String
4: 34740 2768024 [Ljava.lang.Object;
5: 83259 2664288 java.ut...
2018-12-21 13:13
Xstream 对象使用不当导致 CPU 居高不下
公司内某开放平台集群服务出现了些许用户投诉,起初我们不以为意,直到看到了一个很有意思的用户反馈。
开放平台会给根据用户的行为不同推送消息,本来按照正常逻辑,A消息推送永远都会在B消息之前的。
但是用户反馈先收到的B消息,大约十分钟之后收到的A消息,这就有问题了。
我们的消息都是走的kafka,看了下日志的确发生了B消息先推送,A消息后推送的情况,这就不科学了。
首先想到的就是kafka消息积压了,因为A,B两种消息不在一个topic
看了下集群里的机器都会陆续出现CPU暴涨的情况,而且居高不下,一个个接着出现这种情况,

马上看zabbix,找到CPU暴涨的时间段的机器查看它的jstack日志
发现了那台机器有166个RUNNABEL的一样的堆栈信息,别的时间段CPU暴涨的机器的jstack日志也有一模一样的这样的日志,平均都是160+左右。
```
"pool-5-thread-95881" #174383 prio=5 os_pr...
2018-12-11 12:40
kafka 重复消费问题的排查过程
在压力测试过程中,请求的峰值一直持续的时候就容易出现了大量的XX字段插入失败,唯一键冲突。
检查日志能发现出现大量的提交到kafka失败
```
Commit cannot be completed due to group rebalance
```
很多次提交到kafka都是rebalance,为什么发生了rebalance
我们的应用是开三个线程消费kafka消息,拿到消息后就会进行提交,理论上是不应该出现这种情况的。
> kafka 版本在1.0之前是通过客户端poll消息的间隔来判断客户端是否挂掉,1.0 版本改为用单独的线程维持心跳判断是否挂掉。
这个重复消费的集群使用kafka客户端是用的0.9的版本,这就意味着是通过poll消息的间隔来判断是否挂掉。
当poll下消息处理时间超过30秒的时候就会导致发生rebalance,提交失败,紧接着别的机器又消费到了这批消息。
其次,我们把kafka的session超时时间设置由原来的30秒改为了90秒,也就是说间隔时间超过90秒才会rebalance。
改变之后问题不再发生重复消息的情况,
但是日志刷新有卡顿的情况,也就是说有什么逻...
2018-12-05 12:12