go中StructTag的修改问题

2017年5月15日 没有评论

之前发现Field的Tag信息是可修改的,然后真正在用的时候,发现只是修改了当前Field中的StructTag副本,原始信息本未修改。

原文地址:go语言反射遇到的几个问题

更多内容…

分类: 工作 标签: ,

对ThreadPoolExecutor线程启动时机的误解

2017年4月20日 没有评论

为了便于简化日志,上一个小一些的数字

	private final static ThreadPoolExecutor threadPool = new ThreadPoolExecutor(1, 3, 60L, TimeUnit.SECONDS, //
			new ArrayBlockingQueue(5), //
			new TestThreadFactory(), //
			new TestRejectedHandler());

核心线程数是1,最大线程数是3。

按自然的理解方式,线程的规则应该是:在不超总线程数的基础上,尽最大可能让队列空。
也就是说:有三个需要同时处理的任务时,应该启用三个线程。
更多内容…

分类: 工作 标签:

关于GO的赋值

2017年4月5日 没有评论

从Java转Go的童鞋,会对一些Go的特性有误用,比如下面这个

type User struct {
	userId   int64
	userName string
}

func main() {
	userA := User{
		userId:   123321,
		userName: "A",
	}
	userB := userA
	userB.userName = "B"

	fmt.Println("A:", userA.userName, " B:", userB.userName)
}

更多内容…

分类: 工作 标签: , ,

JVM的G1对old区的一次回收日志

2017年3月31日 没有评论

Jvm一共分配60G内存,old区涨到27G+之后,发生一轮old区的大规模回收,结束后old区降为8G。
原本以为会是一次full gc,或一次mixed gc,实际上是以一次带(initial-mark)的较长时间(600+毫秒)young gc开始,然后是一系列处理,其中remark是STW的,且耗时较长(300+毫秒),随后跟着一次young GC和三次mixed GC,这四次GC每一次old区都会下降,第三次mixed GC后,old区降到最低的8G,应该是本轮GC的结束。

找到一遍文章,对G1做了比较详细的解释:Understanding G1 GC Logs
这一轮过程被称为并发标记(concurrent-marking),从[initial-mark]起到[GC concurrent-cleanup-end]止,不包括后面的一次young GC和三次mixed GC。猜测是后续gc时会根据限定的暂停时间自动回收相应的内存。
其中较慢(300+毫秒)的remark(SATB buffers processing) 和较快(20+毫秒)的cleanup是stop-the-world(STW)的。
clean up: Cleanup phase which is again a stop-the-world phase. It goes through the marking information of all the regions, computes the live data information of each region, resets the marking data structures and sorts the regions according to their gc-efficiency.
大意是:Cleanup操作也是STW的,它通过各区标记的信息计算存活对象,重置这些数据结构,然后根据GC的效率对各区排序。

jvm启动参数:

java -server -Xmx60g -Xms60g -XX:MaxGCPauseMillis=300 -XX:PermSize=128m -XX:MaxPermSize=256m -Xss256k -XX:+DisableExplicitGC -XX:+UseG1GC -XX:LargePageSizeInBytes=128m -verbose:gc -Xloggc:/data/logs/gc_xxx.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -jar xxx.jar

先用jstat看整体GC的统计

 [root@xxxx logs]# jstat -gcutil 2450 1000
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
  0.00 100.00  58.62  41.51  71.09   3869  474.469     0    0.000  474.469
  0.00 100.00  59.96  41.51  71.09   3869  474.469     0    0.000  474.469

没有Full GC,OLD区已经从昨天看到的80+%降到41%

更多内容…

go语言反射遇到的几个问题

2017年3月23日 没有评论

一、关于struct的Field反射
1、取结构或值时,传对象和指针都可以。
2、给某struct通过反射赋值时,必须是reflect.ValueOf传指针进去。如果用的是函数的入参且为值参时,对象为副本,取地址也不能设置其值。

二、关于struct的method反射
传入值时,得不到任何method,因为值只包括Field;传指针才可能得到method

三、反射可以得到未导出(首字母小写)的field和method,但不能操作它们,会抛using unexported xxx异常

四、Type有可能被包n层壳,有Ptr和interface两类,可以用Type的.Elem()脱一层壳。

五、Value可以通过interface()方法得到对应的对象实例。Value同样有Ptr和interface的脱壳问题。

六、go没有Java强大的注解,只有Struct tag,神奇的是这个tag是可以在运行时修改的。比如:对象转json时,需要首字母小写,就可以统一来处理,不用手工挨个写。
后经证实,可以修改,但未真正生效,重新反射获取时,还是老的,具体参照:go中StructTag的修改问题

七、struct的method通过反射调用时,struct对象本身会被当成第一个参数,也就是入参看起来比定义的时候多了一个。其实Java也是这么做的。method调用的返回值是[]reflect.value,因为go支持多个返回值。

分类: 工作 标签: , , , ,

两台相似配置服务器负载差异较大

2017年3月9日 没有评论

128G内存,24核CPU的服务器,两台。
分80G内存给jvm,服务和流量相同,jvm进程在一台服务器的cpu负载为350%到400%之间,另一台在800%到1000%之间。
更多内容…

分类: 工作 标签: , , , , ,