熟悉 Java 的多线程的一般都知道会有数据不一致的情况发生，比如两个线程在操作同一个类变量时，而保护数据不至于错乱的办法就是让方法同步或者代码块同步。同步时非原子操作就得同步，比如一个简单的 1.2+1 运算也该同步，以保证一个代码块或方法成为一个原子操作。
简单点说就是给在多线程环境中可能会造成数据破坏的方法，做法有两种，以及一些疑问：
1. 不论是静态的或非静态的方法都加上 synchronized 关键字，那静态的方法和非静态的方法前加上 synchronized 关键字有区别吗？
2. 或者在可疑的代码块两旁用 synchronized(this) 或 synchronized(someObject) 包裹起来，而选用 this 还是某一个对象--someObject，又有什么不同呢？ 阅读全文 >>
一看到 Java NIO 的内存映射文件(MappedByteBuffer)，让我立即就联想到 Windows 系统的内存映射文件。Windows 系统的内存映射文件能用来在多个进程间共享数据，即进程间的共享内存，是通过把同一块内存区域映射到不同进程的地址空间中，从而达到共享内存。
Java NIO 的内存映射文件和 Windows 系统下的一样，都能把物理文件的内容映射到内存中，那么 MappedByteBuffer 是否能用来在不同 Java 进程(JVM) 间共享数据呢？答案是肯定的，这样在通常的 Socket 方式来实现 Java 进程间通信之上又多了一种方法。 阅读全文 >>
1、共享内存对应应用开发的意义
对熟知UNIX系统应用开发的程序员来说，IPC（InterProcess Communication）机制是非常熟悉的，IPC基本包括共享内存、信号灯操作、消息队列、信号处理等部分，是开发应用中非常重要的必不可少的工具。其中共享内存IPC机制的关键，对于数据共享、系统快速查询、动态配置、减少资源耗费等均有独到的优点。
对应UNIX系统来说，共享内存分为一般共享内存和映像文件共享内存两种，而对应Windows，实际上只有映像文件共享内存一种。所以Java应用中，也是只能创建映像文件共享内存。 阅读全文 >>
我们用原有 IO 读写文件应该不会陌生了，顺带回顾一下，大致两种：
1. 在 InputStream 或 OutputStream 上读写字节或字节数组，读 InputStream 时用是否返回 -1 来判断是否到达末尾。
2. 包装成 Reader/Writer 可以直接读写字符串，进一步包装到 BufferedReader/BufferedWriter 就可以按行读写了。readLine() 时看是否返回 null 断定是否读完了最后一行。
现在我们要用 NIO 来读写文件，肯定是要用到 Channel 和 Buffer 了。一句话描述过程就是从 FileInputStream 得到的 FileChannel 中读取数据到 Buffer 中，再处理 Buffer 中的数据。看代码： 阅读全文 >>
对于 NIO 来说，Channel(通道) 和 Buffer(缓冲区) 这两个东西是不得不提的，因为它们是 NIO 的核心对象，几乎每一个 I/O 操作都要它们。
通道是对原 I/O 流的模拟，但有不同的是它是双向的，不再像流那样分 InputStream 和 OutputStream，通道的双向性更好的反映了底层操作系统的真识情况。也不能像原 I/O 那样可以直接往流里写或读数据，在通道了传输数据必须经由缓冲区。有点类似原 I/O 流通过过滤器流 BufferedInputStream 和 BufferedOutputStream 来读写数据。
FileInputStream/FileOutputStream/RandomAccessFile/DatagramSocket/ServerSocket/Socket 的 getChannel() 方法可以获得相应类型的 Channel，Channel 的类型有 FileChannel/SocketChannel/SelectableChannel/DatagramChannel/ServerSocketChannel 等。 阅读全文 >>
Java NIO(New IO) 还是在 JDK 1.4 中引入的新特性。JDK 1.4 的另一重要特性正则表达式大家应该经常用到，但 NIO 就可能使用寥寥了，大概是缘于旧有 IO 体系仍然够用。有如 JDK1.5 早就泛型和注解了，但基于各种原因而无法亲力去实践泛型和注解一般，NIO 多数时候也只是与我们擦着肩而已。
相比与 Old IO，NIO 在某些领域里确有其过人之处，所以现在让我们一起来对 NIO 有个更楚的认识。
NIO 的相关 API，在 java.nio 中，它会与你纠缠的就是各种 Channel 和 Buffer。相关的应用在于处理通道和缓冲区、异步(非阻塞)的 IO、文件的锁定、字符集的处理上。 阅读全文 >>
前记：看到 Twitter 和 Digg 相继用 NoSQL 替代了原有的关系型数据库 MySql。显然，NoSQL 定然有它的许多优势，且目前已有相当的 NoSQL 产品实现，所以有必要对 NoSQL 表示一定的关注，故找些资料来看。它也是非关系型的数据库，那它与著名的文档型数据库 Domino 又有何种关系呢，Java 程序又该如何实际应用 NoSQL 呢？
NoSQL 的官网是：http://nosql-database.org/，里面有丰富的介绍
Wiki 百科上的条目：http://en.wikipedia.org/wiki/NoSQL。以及如下文字：
NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。 阅读全文 >>
IPv4的地址数目高达40亿个，去除了部分私有的和保留的IP地址后，互联网上可能出现的公有地址数量依然相当可观（虽然这些地址仍然不够用），在经过汇总和合理的分配之后，互联网上的路由条目仍然有接近30万条！运行在互联网上的路由器为了可以选择最佳的路径达到全球目的地，有必要接收大部分甚至所有的路由条目，想必很多人会对这个包含全球路由的BGP路由表深感兴趣吧？Let‘s check it out！
1.打开SecureCRT或者Putty甚至系统自带的telnet程序（不建议用系统自带的）
2.telnet 这个地址：route-server.ip.att.net
3.接着就会收到一些欢迎信息，和提示要求输入用户名，输入rviews 阅读全文 >>
原文：101 on jQuery Selector Performance by Andreas Grabner, Nov 09, 09
上周我认真分析了一个 Web 页面，它在 onLoad 事件中处理一段定制脚本文件用了 4.8 秒。结果是其中 2.8 秒消耗在动态菜单库上(将会在博客中单独记录)，剩下的 2 秒花费在 jQuery 的选择器上。分析显示多数选择器不返回任何对象，而那些会返回对象的选择器可考虑用不同的选择器来改善性能。
关于 jQuery 选择器
有大量的日志文章论述了 jQuery 选择器及它们的性能影响。正如你所知，可以通过 ID, TagName 或 ClassName 选择元素。依赖于不同的选择器， jQuery 会使用浏览器本地方法，如 通过 ID 或标签来选择元素，或者在使用类名选择时须手工从 DOM 中遍历获得元素(因为在 IE 中不存在相应的 getElementsByClssName).
分析我的页面时间中这 2 秒
在 onLoad 处理器中对页面中某些特定的元素使用 jQuery 设置为隐藏，显示或改变样式表...。这里是一个代码片断： 阅读全文 >>
现代 Web 设计与开发越来越看重浏览器兼容问题，IE 每个新版本的推出，都在 CSS 的标准化方面前进一大步，同时，也就不可避免地在 IE 的各个主要版本之间产生兼容问题，尽管 IE8 推出已有时日，使用 IE6的用户仍然相当可观。本文以速查手册的形式介绍 CSS （2.1 和 3）在 IE6,7,8 三个版本之间的兼容情况。
这套速查手册可以打印成 A3 尺寸，共2页，以下是各种不同格式下载：
本文来源：http://tutorialfeed.blogspot.com/2009/10/visual-cheat-sheet-css-compatiblity.html
翻译整理：COMSHARP CMS 企业网站内容管理系统官方网站