T********i
发帖数: 2416 | 1 2008年我做过一个实时Java系统，用Object Pool + RTSJ，响应能达到两位数的微秒。
这个每天要重启数次的系统。不是我的系统。用Java做的。干脆就是连Object pool都
懒得用。是2010年以后做的新系统。现在还在production。
这个系统号称是disable GC。现在看来也可能是不停monitor heap。别人的系统我没兴
趣搞细节。但是其以前用户是我的搭档。每天可控的重启是肯定的。
我当时想说的是，即使用duct tape做一个系统，也能用。 |
g*****g
发帖数: 34805 | 2 object pool 在哪里你弄明白了吗， object跟 class的区别你弄明白了吗？三天不打
脸就难受是吧。
【在 T********i 的大作中提到】
: 2008年我做过一个实时Java系统，用Object Pool + RTSJ，响应能达到两位数的微秒。
: 这个每天要重启数次的系统。不是我的系统。用Java做的。干脆就是连Object pool都
: 懒得用。是2010年以后做的新系统。现在还在production。
: 这个系统号称是disable GC。现在看来也可能是不停monitor heap。别人的系统我没兴
: 趣搞细节。但是其以前用户是我的搭档。每天可控的重启是肯定的。
: 我当时想说的是，即使用duct tape做一个系统，也能用。
|
T********i
发帖数: 2416 | 3 你这个就无聊了吧？
我多年前曾经费尽心思要找把数据allocate在permgen的方法。看来这个Java还是个费
二遍事的。
【在 g*****g 的大作中提到】
: object pool 在哪里你弄明白了吗， object跟 class的区别你弄明白了吗？三天不打
: 脸就难受是吧。
|
z****e
发帖数: 54598 | 4 啧啧
这个还用找么？
一个关键字就放过去了
【在 T********i 的大作中提到】
: 你这个就无聊了吧？
: 我多年前曾经费尽心思要找把数据allocate在permgen的方法。看来这个Java还是个费
: 二遍事的。
|
z****e
发帖数: 54598 | 5 内行一听就知道disable gc是bullshit
这都能被忽悠 |
T********i
发帖数: 2416 | 6 多年不用。没牵狗。我的错误我认。
但是这个每天到时停止交易recycle的Java系统倒是客观存在。每年维护就要上百万。
也算是Java系统的一个典范吧。
【在 z****e 的大作中提到】
: 啧啧
: 这个还用找么？
: 一个关键字就放过去了
|
z****e
发帖数: 54598 | 7 gc到点执行
这个倒是可以实现的
这些年gc策略也作了很大调整
各种策略各有优劣
一个比较常见的
简单说就是，先GC，要求GC停顿控制在一定时间范围之内
如果超过了，就先停止gc，继续执行，等下一个再执行gc
哪怕用system.gc()也可以做到一些非精确的GC执行
你离开这行是有些年头了
【在 T********i 的大作中提到】
: 多年不用。没牵狗。我的错误我认。
: 但是这个每天到时停止交易recycle的Java系统倒是客观存在。每年维护就要上百万。
: 也算是Java系统的一个典范吧。
|
T********i
发帖数: 2416 | 8 这个可能是实时监测heap。也是我想复杂了。
我任何应用都能用更简单的方法完成，为啥要用Java呢？
【在 z****e 的大作中提到】
: gc到点执行
: 这个倒是可以实现的
: 这些年gc策略也作了很大调整
: 各种策略各有优劣
: 一个比较常见的
: 简单说就是，先GC，要求GC停顿控制在一定时间范围之内
: 如果超过了，就先停止gc，继续执行，等下一个再执行gc
: 哪怕用system.gc()也可以做到一些非精确的GC执行
: 你离开这行是有些年头了
|
x****u
发帖数: 44466 | 9 你这个实时没考虑的修改系统的时间吧。
【在 T********i 的大作中提到】
: 这个可能是实时监测heap。也是我想复杂了。
: 我任何应用都能用更简单的方法完成，为啥要用Java呢？
|
T********i
发帖数: 2416 | 10 不懂。
【在 x****u 的大作中提到】
: 你这个实时没考虑的修改系统的时间吧。
|
|
|
c******3
发帖数: 296 | 11 许多公司会半夜重启服务器，周末重启桌面。效果上和GC差不多，顺带把OS里的垃圾也
清了。 |
T********i
发帖数: 2416 | 12 我的一些process做成service跟机器走。经常一年半载才想起重启一下。
【在 c******3 的大作中提到】
: 许多公司会半夜重启服务器，周末重启桌面。效果上和GC差不多，顺带把OS里的垃圾也
: 清了。
|
c******3
发帖数: 296 | 13 jboss不是一般的烂，不时不时重启一下，就死给你看。 |
z****e
发帖数: 54598 | 14 这个多半是你们写的代码内存泄露了
找个工具来看看哪里ref没有释放吧
【在 c******3 的大作中提到】
: jboss不是一般的烂，不时不时重启一下，就死给你看。
|
c******3
发帖数: 296 | 15 这是很可能的。但有意思的是有时jboss重启也启不来，最后只好把cluster里的jboss
都重启一遍。jboss来人看了一下，也没分析出个结果。
【在 z****e 的大作中提到】
: 这个多半是你们写的代码内存泄露了
: 找个工具来看看哪里ref没有释放吧
|
h**********c
发帖数: 4120 | 16 met similiar problem. My personal analysis is that in the application
holding some system resource socket etc. not confirmed
finally run a cron job, undeploy the app/ redeploy the app, restart jboss at
midnight when no users. That is a single jboss not in cluster.
jboss
【在 c******3 的大作中提到】
: 这是很可能的。但有意思的是有时jboss重启也启不来，最后只好把cluster里的jboss
: 都重启一遍。jboss来人看了一下，也没分析出个结果。
|
z****e
发帖数: 54598 | 17 都是老大难问题
这种我也没有特别好的办法
我看stackoverflow上也没啥特别好的方法
也只能一点一点分析
http://stackoverflow.com/questions/40119/how-to-find-a-java-mem
jboss
【在 c******3 的大作中提到】
: 这是很可能的。但有意思的是有时jboss重启也启不来，最后只好把cluster里的jboss
: 都重启一遍。jboss来人看了一下，也没分析出个结果。
|
b********e
发帖数: 595 | 18
jboss
内存泄漏不太容易查，不知道这些年是不是进步了，以前的时候只能heap dump,多dump
几次比较，生产上dump经常就死菜了，线下测只能靠猜。
一般都是先试thread dump，tda分析，只能大概看看jvm里面thread调用和锁定关系。
【在 c******3 的大作中提到】
: 这是很可能的。但有意思的是有时jboss重启也启不来，最后只好把cluster里的jboss
: 都重启一遍。jboss来人看了一下，也没分析出个结果。
|
z****e
发帖数: 54598 | 19 re这个
内存泄露，死锁都是一般大项目中灰常头疼的问题
dump
【在 b********e 的大作中提到】
:
: jboss
: 内存泄漏不太容易查，不知道这些年是不是进步了，以前的时候只能heap dump,多dump
: 几次比较，生产上dump经常就死菜了，线下测只能靠猜。
: 一般都是先试thread dump，tda分析，只能大概看看jvm里面thread调用和锁定关系。
|
b********e
发帖数: 595 | 20
这些是通过G1的参数控制的吧，自己控制gc的好像最开始有过，后来都是换不同的gc，
设置下参数，一般都能控制好了。有些年不调jvm了，以前用CMS gc效果就不错，不知
道这些年又搞什么新的花样了。
【在 z****e 的大作中提到】
: gc到点执行
: 这个倒是可以实现的
: 这些年gc策略也作了很大调整
: 各种策略各有优劣
: 一个比较常见的
: 简单说就是，先GC，要求GC停顿控制在一定时间范围之内
: 如果超过了，就先停止gc，继续执行，等下一个再执行gc
: 哪怕用system.gc()也可以做到一些非精确的GC执行
: 你离开这行是有些年头了
|
b********e
发帖数: 595 | 21
死锁容易定位，tomat直接kill -3, jboss通过jmx能看到heap dump, tda一看就能看出
来，查内存泄漏的确是个力气活
【在 z****e 的大作中提到】
: re这个
: 内存泄露，死锁都是一般大项目中灰常头疼的问题
:
: dump
|
g*****g
发帖数: 34805 | 22 Memory Analyzer etc. has make it fairly easy to detect leak.
What's leaking can typically be identified by taking two snapshots and
compare.
【在 b********e 的大作中提到】
:
: 死锁容易定位，tomat直接kill -3, jboss通过jmx能看到heap dump, tda一看就能看出
: 来，查内存泄漏的确是个力气活
|
