64位Linux下Java进程堆外内存迷之64M问题
起因,监控系统检查到link机器内存耗尽,用top查看,果然有一个java进程占用了近24g内存(包括VIRT和RES),但是启动java进程的参数是java -server -Xmx12g -Xms12g -XX:PermSize=50m,理论上只应该占用12g再多一些,所以问题就在这个进程了。此进程主要处理Socket IO读写,使用的是Java NIO。
起因,监控系统检查到link机器内存耗尽,用top查看,果然有一个java进程占用了近24g内存(包括VIRT和RES),但是启动java进程的参数是java -server -Xmx12g -Xms12g -XX:PermSize=50m,理论上只应该占用12g再多一些,所以问题就在这个进程了。此进程主要处理Socket IO读写,使用的是Java NIO。
为了实现不同IM(即时通讯软件,比如QQ、GTalk)之间可以互相通信,jabber和XMPP为此而生。jabber是Linux中的一个程序,设计了一套开源的协议,用于连接不通的IM,然后XMPP以jabber协议为基础并扩展之。每一个IM程序服务端与客户端之间肯定有一套保密并加密的协议,这个是不可能容易让外部获知的,不然IM软件聊天内容就泄露了,谁还敢用。XMPP是让不同的IM之间互相通信,跟IM程序本身毫无关系。
如题,在like搜索中不区分大小写是OK的,但是用=匹配也不区分感觉就有点怪了,具体看项目看需求。此次碰到从数据库中读数据读到了大小写数据,但是代码中却是区分大小写又拦截掉了,导致数据的不一致情况出现。
这是一本好书(Java源码作者Doug Lea是作者之一),关于Java并发的各个方面,介绍的很深入,应该算是进阶一类,很多地方不好理解。一开始打算阅读英文版,倒不是英文看不懂,不过还是有很多内容的确理解起来很费劲,尤其是老外写书的风格(废话特别多 = = 一页密密麻麻的英文,让人找不到关键点在哪儿),看几页就没兴趣再看下去哎…后有幸找到了中文翻译版,而且翻译的很有水准,拜谢翻译工作者韩锴和方妙。
找不到翻译版的同学,可以私信我提供。
执行脚本遇到一个情况,脚本无法自动退出完毕,必须手动执行Ctrl-C才能退出,之前遇到过这个问题是因为数据库连接没有被正确关闭导致,这次的原因是一个另起的线程没有正常停止的原因。
Callable、Future和FutureTask,结合Executors和ExecutorService,将某些特定的计算任务交给其他线程(由统一的线程池管理),让主线程进行阻塞和等待执行结果,用在RPC服务比较直观,或者这个计算结果被多个线程所需等情况。
从整体上看,使用FutureTask降低了程序整体的效率,肯定不如在原线程中直接执行的快,而且因为主线程需要阻塞等待计算结果,所以并没有增加并发度。所以FutureTask在项目中一般也比较少见。
阅读更多…
java.util.concurrent.Semaphore
AQS实现的一个变种,用来预先设置一个阈值(可进入量),然后当做类似共享锁的方式地进行acquire和release,但是每次acquire不记录当前acquire的线程对象(这是Semaphore和Lock最大的区别)
,即线程A操作的acquire可以由线程B来release。也有公平和非公平两种方式。
也是利用AQS实现的一个变种,用来预先设置一个阈值(任务数)后主线程调用await()持续阻塞,然后由其他线程执行任务,执行完后调用countDown()将阈值减1,当所有任务执行完毕,阈值减为0,主线程await()被唤醒跳出阻塞,继续执行。 阅读更多…
AQS的另一个实现,可重入的读写锁,其中读锁是共享锁,写锁是排他锁。用法和ReentrantLock基本一致。 阅读更多…
本文简单介绍可重入锁的概念,简单介绍java中内置的synchronized锁
和java.util.concurrent.locks.ReentrantLock
,然后大致介绍下ReentrantLock的代码实现。ReentrantLock和AQS代码逻辑真心复杂和难懂,尤其是AQS中Node的ws值中的SIGNAL值的用法和线程park/unpark的用法,持续几周看了好几天终于算是给弄明白了! 阅读更多…
开发时因为更新代码,频繁重启Tomcat,遇到一个问题:在执行shutdown脚本后,Tomcat进程没有关闭依然存在(但是HTTP服务已经停止),需要手动执行kill命令才行。查了一些资料结合经验,应该是所使用的数据库连接池中的连接没有被释放的问题引起的。所以解决的办法,就是想办法做一个Tomcat的shutdown的事件监听,然后手动释放数据库连接即可。 阅读更多…
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" acceptorThreadCount="8" executor="tomcatThreadPool" URIEncoding="UTF-8" compression="on" compressableMimeType="text/html,text/css,application/javascript,text/xml,text/plain" connectionTimeout="20000" redirectPort="8443" /> |
主要是compression和compressableMimeType两行。
Tomcat7中,必须是application/javascript,而不能使text/javascript。
注意如果开启了https服务,在
想法:Spring-mvc(Spring v3.2)中,仅对注册过(通过@RequestMapping
注解)的url进入到controller层,其他非法url在Filter里就拦截掉,统一处理节省资源。因为在filter的doChain之前,给本次请求从对象池中获取一个操作db的对象,对无效url也分配的话就浪费了资源。
实现:通过Spring-mvc的RequestMappingHandlerMapping
来获取注册过的url path,再根据HttpServletRequest,判断下就可以进行过滤。
3月以来,从来运行正常的link无故崩了好多次,现象:无异常日志,用jstack看主线程挂了进程还在,主线程最外层有catch异常,但是并没有打印日志,实在匪夷所思。