Sun, 21 Jun 2009 15:52:00 GMTJava技术研究与实践http://blog.csdn.net/kabini/http://blog.csdn.net/kabini/archive/2009/06/21/4286737.aspxhttp://blog.csdn.net/kabini/comments/4286737.aspx0http://blog.csdn.net/kabini/comments/commentRss/4286737.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=4286737相信现在做Java的人没有人不用NIO来进行IO相关的操作了吧。这个新的IO类库[虽然现在已经不新了]为我们带来了基于块的IO处理方式，通过预定义的Buffer，我们可以更高效地完成IO操作。在NIO中，我比较关注的是一个成为mmap的文件映射功能，其特点是可以把文件的一部分或全部映射到内存中，之后我们就可以通过MappedBuffer对内存进行操作，而操作的结果会由操作系统负责flush到文件中。由于应用程序只是操作内存，所以处理速度比普通的文件操作快很多，在某些应用场景下mmap可以发挥相当大的作用。本文就来揭秘java的mmap背后的工作原理和实现方法，以及使用java的mmap要注意的一些问题。<img src ="http://blog.csdn.net/kabini/aggbug/4286737.aspx" width = "1" height = "1" /><img src="http://www1.feedsky.com/t1/236665754/kabini/csdn.net/s.gif?r=http://blog.csdn.net/kabini/archive/2009/06/21/4286737.aspx" border="0" height="0" width="0" style="position:absolute" /><p class="fswww1"><a href="http://www1.feedsky.com/r/l/csdn.net/kabini/236665754/art01.html" target="_blank"><img border="0" ismap="ismap" src="http://www1.feedsky.com/r/i/csdn.net/kabini/236665754/art01.gif" onerror="this.style.display='none'" /></a></p>Sun, 21 Jun 2009 23:52:00 +0800http://blog.csdn.net/kabini/archive/2009/06/21/4286737.aspx#Feedbackhttp://blog.csdn.net/kabini/archive/2009/06/21/4286737.aspxhttp://blog.csdn.net/kabini/archive/2009/06/21/4286737.aspxhttp://blog.csdn.net/kabini/feed.aspxcsdn.net/kabini/~1072837/236665754/1072836http://blog.csdn.net/kabini/archive/2009/05/29/4223810.aspxhttp://blog.csdn.net/kabini/comments/4223810.aspx2http://blog.csdn.net/kabini/comments/commentRss/4223810.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=4223810前几天在公司听了一个老外的讲座，内容和标题一样，是应用Key Conception进行敏捷软件开发，感觉有所收获，拿出来共享一下。<img src ="http://blog.csdn.net/kabini/aggbug/4223810.aspx" width = "1" height = "1" /><img src="http://www1.feedsky.com/t1/236665755/kabini/csdn.net/s.gif?r=http://blog.csdn.net/kabini/archive/2009/05/29/4223810.aspx" border="0" height="0" width="0" style="position:absolute" /><p class="fswww1"><a href="http://www1.feedsky.com/r/l/csdn.net/kabini/236665755/art01.html" target="_blank"><img border="0" ismap="ismap" src="http://www1.feedsky.com/r/i/csdn.net/kabini/236665755/art01.gif" onerror="this.style.display='none'" /></a></p>Fri, 29 May 2009 20:08:00 +0800http://blog.csdn.net/kabini/archive/2009/05/29/4223810.aspx#Feedbackhttp://blog.csdn.net/kabini/archive/2009/05/29/4223810.aspxhttp://blog.csdn.net/kabini/archive/2009/05/29/4223810.aspxhttp://blog.csdn.net/kabini/feed.aspxcsdn.net/kabini/~1072837/236665755/1072836http://blog.csdn.net/kabini/archive/2009/04/07/4053750.aspxhttp://blog.csdn.net/kabini/comments/4053750.aspx0http://blog.csdn.net/kabini/comments/commentRss/4053750.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=4053750先说些题外话，Java的内存管理一直是让人又爱又恨玩意。学生时代写Java程序主要考虑的只是实现算法、完成功能，偶尔碰到OutofMemory也是递归搞成死循环。什么垃圾回收、内存管理统统交给JVM去烦恼。上班之后再用Java发现完全不是那么回事，大访问量的情况下如何减少fullgc和停顿时间，内存管理无法由程序员控制和干预、甚至无法获知究竟哪个部分用了多少内存有时着实让人有些抓狂。各位可能无法想象当我们撞大运般的用jdk6_u12代替之前的某个版本解决了困扰多时的内存在高峰期无法正常回收的问题（后面会提到）时，那种如释重负却又心有不甘的感觉。因为存在对于内存管理丝毫插不上手的无力感，从那时起，我就一直在寻找一种把数据丢到内存里但又能够对其有所控制的方法，mmap算是不错的选择。<img src ="http://blog.csdn.net/kabini/aggbug/4053750.aspx" width = "1" height = "1" /><p class="fswww1"><a href="http://www1.feedsky.com/r/l/csdn.net/kabini/236665756/art01.html" target="_blank"><img border="0" ismap="ismap" src="http://www1.feedsky.com/r/i/csdn.net/kabini/236665756/art01.gif" onerror="this.style.display='none'" /></a></p>Tue, 07 Apr 2009 19:43:00 +0800http://blog.csdn.net/kabini/archive/2009/04/07/4053750.aspx#Feedbackhttp://blog.csdn.net/kabini/archive/2009/04/07/4053750.aspxhttp://blog.csdn.net/kabini/archive/2009/04/07/4053750.aspxhttp://blog.csdn.net/kabini/feed.aspxcsdn.net/kabini/~1072837/236665756/1072836http://blog.csdn.net/kabini/archive/2009/01/13/3771225.aspxhttp://blog.csdn.net/kabini/comments/3771225.aspx0http://blog.csdn.net/kabini/comments/commentRss/3771225.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=3771225最近国家打击“低俗”，其它同事都忙着让自己的业务“不低俗”，而我则因为业务不低俗相对轻松许多,就想早点下班回家，但是这时候那个万恶的短信声音又一次响起来了。唉，又是那个报警，这个报警从上午10点左右开始就一直持续不断，但主要又是一些非重要、调用量较少的接口，而且整个白天时有时无，就没太在意，但是到了用户高峰期的时候报警愈发频繁，于是我不得不打消回家的念头，搞定这个问题才行。<img src ="http://blog.csdn.net/kabini/aggbug/3771225.aspx" width = "1" height = "1" /><p class="fswww1"><a href="http://www1.feedsky.com/r/l/csdn.net/kabini/236665757/art01.html" target="_blank"><img border="0" ismap="ismap" src="http://www1.feedsky.com/r/i/csdn.net/kabini/236665757/art01.gif" onerror="this.style.display='none'" /></a></p>Wed, 14 Jan 2009 05:15:00 +0800http://blog.csdn.net/kabini/archive/2009/01/13/3771225.aspx#Feedbackhttp://blog.csdn.net/kabini/archive/2009/01/13/3771225.aspxhttp://blog.csdn.net/kabini/archive/2009/01/13/3771225.aspxhttp://blog.csdn.net/kabini/feed.aspxcsdn.net/kabini/~1072837/236665757/1072836http://blog.csdn.net/kabini/archive/2008/09/24/2975263.aspxhttp://blog.csdn.net/kabini/comments/2975263.aspx2http://blog.csdn.net/kabini/comments/commentRss/2975263.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2975263对于一般的Java应用而言，类装载器是透明的，我们在做普通的Java桌面应用程序和Web程序的时候也很少会与ClassLoader打交道。但是当我们深入地研究一些WebServer（如Tomcat）的时候，发现里面用到了很复杂的自定义类装载器体系结构，想要了解其工作过程首先就要理解它是如何载如类的。此外，当我们明明在ClassPath下指定了正确的jar包，却莫名其妙地受到ClassNotFound错误，或者我们放到ClassPath下的类没有被正确载入的时候，就需要和ClassLoader打交道了。这里我不打算讨论基本的JVM的类装载器体系结构和原理，因为这些东西已经在《Java深度历险》或者《Inside Of JVM》里讲的很透彻了。本文旨在分享一下我对于各种文档上都很少提及的Context Class Loader的一些理解。虽然不是点到为止，但是肯定多有疏漏之处，希望对此有研究的朋友留言帮我补充，现行谢过。<img src ="http://blog.csdn.net/kabini/aggbug/2975263.aspx" width = "1" height = "1" /><p class="fswww1"><a href="http://www1.feedsky.com/r/l/csdn.net/kabini/236665758/art01.html" target="_blank"><img border="0" ismap="ismap" src="http://www1.feedsky.com/r/i/csdn.net/kabini/236665758/art01.gif" onerror="this.style.display='none'" /></a></p>Thu, 25 Sep 2008 06:59:00 +0800http://blog.csdn.net/kabini/archive/2008/09/24/2975263.aspx#Feedbackhttp://blog.csdn.net/kabini/archive/2008/09/24/2975263.aspxhttp://blog.csdn.net/kabini/archive/2008/09/24/2975263.aspxhttp://blog.csdn.net/kabini/feed.aspxcsdn.net/kabini/~1072837/236665758/1072836http://blog.csdn.net/kabini/archive/2008/06/30/2598524.aspxhttp://blog.csdn.net/kabini/comments/2598524.aspx7http://blog.csdn.net/kabini/comments/commentRss/2598524.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2598524前言：说实话，所有游戏都是有一定规律可循的，只要掌握游戏规则通关就会变得容易，所以像九连环和魔方这样的游戏会产生看一眼之后就闭着眼睛完成的高手出现。但是数独游戏有所不同，如果其初始状态的生成过程充分随机且空白比较多的话就不那么容易解决，所以数独矩阵的生成就是本题的关键。以往我的关注点主要在补充书中算法的遗漏或不足上面，但是由于感觉这个游戏确实挺好玩，而且作者也没把他的源码公布出来，所以我就利用书中的算法和自己想的算法作了一个数独生成器出来，大家有兴趣的话可以留言管我要，不过要回答本文最后提出的问题才可以:)。<img src ="http://blog.csdn.net/kabini/aggbug/2598524.aspx" width = "1" height = "1" /><p class="fswww1"><a href="http://www1.feedsky.com/r/l/csdn.net/kabini/236665759/art01.html" target="_blank"><img border="0" ismap="ismap" src="http://www1.feedsky.com/r/i/csdn.net/kabini/236665759/art01.gif" onerror="this.style.display='none'" /></a></p>Mon, 30 Jun 2008 23:40:00 +0800kabinihttp://blog.csdn.net/kabini/archive/2008/06/30/2598524.aspx#Feedbackhttp://blog.csdn.net/kabini/archive/2008/06/30/2598524.aspxkabinihttp://blog.csdn.net/kabini/archive/2008/06/30/2598524.aspxhttp://blog.csdn.net/kabini/feed.aspxcsdn.net/kabini/~1072837/236665759/1072836http://blog.csdn.net/kabini/archive/2008/06/16/2553505.aspxhttp://blog.csdn.net/kabini/comments/2553505.aspx4http://blog.csdn.net/kabini/comments/commentRss/2553505.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2553505看着本书主页上长长的勘误表，我真的替能拿到第一版第二次印刷的朋友们开心，相信在经过调整之后阅读效果会更好。同时，本书的作者和编辑没有匆忙推出第二版也是一种很负责任的行为，花多一点的修改酝酿，会让我对第二版产生更多的期待，这也是一本书成为经典的必经之路。虽然我在上一篇书评中比较激烈的批评了书中算法论证不够严密的缺点，但是那是因为我没看到1.11-1.13中描述的拈石头游戏问题，这三节看过之后心里唯有“爽快”二字，要是所有章节都能达到这种质量，我觉得就没有任何遗憾了。但是所有章节都这样写可能会令很多人感到枯燥，毕竟众口难调，而且有些问题的解决也确实不需要细到这种程度；此外，这本书是多个作者合著，风格上确实很难做到统一。不过这些难题还是留给作者头痛好了，我还是开开心心写书评。<img src ="http://blog.csdn.net/kabini/aggbug/2553505.aspx" width = "1" height = "1" /><p class="fswww1"><a href="http://www1.feedsky.com/r/l/csdn.net/kabini/236665760/art01.html" target="_blank"><img border="0" ismap="ismap" src="http://www1.feedsky.com/r/i/csdn.net/kabini/236665760/art01.gif" onerror="this.style.display='none'" /></a></p>Mon, 16 Jun 2008 23:58:00 +0800kabinihttp://blog.csdn.net/kabini/archive/2008/06/16/2553505.aspx#Feedbackhttp://blog.csdn.net/kabini/archive/2008/06/16/2553505.aspxkabinihttp://blog.csdn.net/kabini/archive/2008/06/16/2553505.aspxhttp://blog.csdn.net/kabini/feed.aspxcsdn.net/kabini/~1072837/236665760/1072836http://blog.csdn.net/kabini/archive/2008/04/21/2311946.aspxhttp://blog.csdn.net/kabini/comments/2311946.aspx6http://blog.csdn.net/kabini/comments/commentRss/2311946.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2311946从买书那天算起，到今天已经过了半个多月。这段时间说短不短，如果是一本300多页的小说的话，我大概一天就能搞定（我的记录是一天一千多页《大唐双龙传》），但是到现在《编程之美》我只看了不到50页。虽然我不是天天看，但是一旦我看了一个问题之后，我就希望能够把这个问题在算法层面分析透，这份专注是我以前看《算法导论》或者上算法课的时候所不曾体会到的。究其原因，主要还是纯粹的理论流于枯燥，纯粹的应用不免肤浅，而这本书的定位刚刚好，既能够以应用带动算法的学习，又能够避免过于说教的风格。<img src ="http://blog.csdn.net/kabini/aggbug/2311946.aspx" width = "1" height = "1" /><p class="fswww1"><a href="http://www1.feedsky.com/r/l/csdn.net/kabini/236665761/art01.html" target="_blank"><img border="0" ismap="ismap" src="http://www1.feedsky.com/r/i/csdn.net/kabini/236665761/art01.gif" onerror="this.style.display='none'" /></a></p>Mon, 21 Apr 2008 22:44:00 +0800kabinihttp://blog.csdn.net/kabini/archive/2008/04/21/2311946.aspx#Feedbackhttp://blog.csdn.net/kabini/archive/2008/04/21/2311946.aspxkabinihttp://blog.csdn.net/kabini/archive/2008/04/21/2311946.aspxhttp://blog.csdn.net/kabini/feed.aspxcsdn.net/kabini/~1072837/236665761/1072836http://blog.csdn.net/kabini/archive/2008/04/16/2296943.aspxhttp://blog.csdn.net/kabini/comments/2296943.aspx6http://blog.csdn.net/kabini/comments/commentRss/2296943.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2296943每次看完《编程之美》中的问题，想要亲自演算一下或深入思考的时候，都觉得时间过得很快，动辄一两个小时，如果再把代码敲一遍的话，需要的时间可能更长，真是搞不懂通过微软面试的那些家伙的脑袋到底什么构造，书的序言中提到他们每次面试45分钟，还要写出程序？！在我看来，如果是控制CPU曲线或是中国象棋问题或许还有可能，如果是买书折扣问题，我觉得真的是不太容易，尤其是如果当面试者钻进本题的贪心解法而不是动态规划算法的思路之后，因为我写这篇文章前前后后大概用了5个小时 :-( 。不过我想只要是学习就不是浪费时间，今天上网看到微软的校园招聘网站又有更新，等我把这本书看完，就投简历过去试一试 :-) 。<img src ="http://blog.csdn.net/kabini/aggbug/2296943.aspx" width = "1" height = "1" /><p class="fswww1"><a href="http://www1.feedsky.com/r/l/csdn.net/kabini/236665762/art01.html" target="_blank"><img border="0" ismap="ismap" src="http://www1.feedsky.com/r/i/csdn.net/kabini/236665762/art01.gif" onerror="this.style.display='none'" /></a></p>Wed, 16 Apr 2008 22:10:00 +0800kabinihttp://blog.csdn.net/kabini/archive/2008/04/16/2296943.aspx#Feedbackhttp://blog.csdn.net/kabini/archive/2008/04/16/2296943.aspxkabinihttp://blog.csdn.net/kabini/archive/2008/04/16/2296943.aspxhttp://blog.csdn.net/kabini/feed.aspxcsdn.net/kabini/~1072837/236665762/1072836http://blog.csdn.net/kabini/archive/2008/04/14/2289990.aspxhttp://blog.csdn.net/kabini/comments/2289990.aspx5http://blog.csdn.net/kabini/comments/commentRss/2289990.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2289990前面已经写了一些关于烙饼问题的简单分析，但因为那天太累有些意犹未尽，今天再充实一些内容那这个问题研究透。我想，通过这篇文章，我们就可以把这一类问题搞懂。再遇到优化问题，如果我们想不到别的办法，就可以采用搜索树算法来解决，至少我们不至于拿不出解决方案。前面我们已经知道，关于一摞烙饼的排序问题我们可以采用递归的方式来完成。其间我们要做的是尽量调整UpperBound和LowerBound，已减少运算次数。对于这种方法，在算法课中我们应该称之为：Tree Searching Strategy。即整个解空间为一棵搜索树，我们按照一定的策略遍历解空间，并寻找最优解。一旦找到比当前最优解更好的解，就用它替换当前最优解，并用它来进行“剪枝”操作来加速求解过程。<img src ="http://blog.csdn.net/kabini/aggbug/2289990.aspx" width = "1" height = "1" /><p class="fswww1"><a href="http://www1.feedsky.com/r/l/csdn.net/kabini/236665763/art01.html" target="_blank"><img border="0" ismap="ismap" src="http://www1.feedsky.com/r/i/csdn.net/kabini/236665763/art01.gif" onerror="this.style.display='none'" /></a></p>Mon, 14 Apr 2008 18:30:00 +0800kabinihttp://blog.csdn.net/kabini/archive/2008/04/14/2289990.aspx#Feedbackhttp://blog.csdn.net/kabini/archive/2008/04/14/2289990.aspxkabinihttp://blog.csdn.net/kabini/archive/2008/04/14/2289990.aspxhttp://blog.csdn.net/kabini/feed.aspxcsdn.net/kabini/~1072837/236665763/1072836