遇到过这样一个情况，需要用java读取一个200M的文本格式文件，而且还需要对文件的内容做解析，进行分词。如果用JVM的默
认设置，利用Scanner类只能读出4M大小内容，于是我就在网上搜索，但是网上没有找到一篇文章是我所需要的内容。于是我只好翻thinking
in
java，发现了一个java的nio里有个MappedByteBuffer类，他的作用可以把一个文件映射到内存中，然后就能像访问数组一样去读取这
个文件。于是我在JDK中查了MappedByteBuffer的详细的用法，然后将其和Scanner类结合一下，便能得到一边读取大文件，一边解析读
取的内容了功能了，具体的代码如下：
public void readResource() {
long fileLength = 0;
final int BUFFER_SIZE = 0x300000;// 3M的缓冲
for(String fileDirectory:this.readResourceDirectory())//得到文件存放路径，我这里使用了一个方法从XML文件中读出文件的
//存放路径，当然也可以用绝对路径来代替这里的fileDriectory
{
File file = new File(fileDirectory); ......
If the requested address is not a valid virtual memory address (it doesn't belong to any of
the memory segments of the executing process), the page cannot be validated, and
a segmentation fault is generated. This vectors control to another part of the kernel and
usually results in the process being killed.
如果被请求的地址不是一个有效虚拟内存地址（它不属于任何当前进程的内存段中），则页不能被确认，一个段错误会被生成。控制会被转移到内核的别的部分，常常导致进程被杀死
Once the faulted page has been made valid, the MMU is updated to establish the new virtualto-
physical mapping (and if necessary, break the mapping of the stolen page), and the user
process is allowed to resume. The process causing the page fault will not be aware of any of
this; it all happens transparently.
一旦页错误被确认有效，MMU就会更新，把新的虚拟-物理映射见了起来（如果必须，把被偷的页面的映射捣毁），然后用户进程就被允许继续了。导致了页错误的进程对此一无所知，对它而言这些是透明的。
This dynamic shuffl ......
首先了解下所谓的java nio是个什么东西！
IO是靠字符或字节进行传输，比较慢！ 而NIO是靠块， 也就相当于一个Buffer， 一块一块
的传输， 速度较快
！ 同时加入了多线程
的控制， 一个NIO流可以同时传输多个块等， 也就是所谓的异步传输
；
传统
的并发型
服务器设计是利用阻塞型网络I/O
以多线程的模式（一个SOCKET链接，服务端就启动一个线程接受服务
）来实现的，然而由
于系统常常在进行网络读写时处于阻塞状态，会大大影响系统的性能
；自Java1. 4 开始引入
了NIO(新I/O) API，通过使用非阻塞型
I/O
，实现流畅的网络读写操作，为开发高性能并发
型服务器程序提供了一个很好的解决方案。这就是java nio
首先来看下传统的阻塞型网络 I/O的不足 Java 平台传统的I/O 系统都是基于Byte（字节）和Stream（数据流）的，相应的I/O 操作都是阻塞型的
，
所以服务器程序也采用阻塞型I/O
进行数据的读、写操作。本文以TCP长连接模式来讨论并发型服务器的相关设计，为了实现服务器程序的并发性要求，系统由一个单独的主线程来监听用户发起的
连接请求，一直处于阻塞状态；当有用户连接请求到来时，程序都会启一个新的线程来统一处理用户数据的读 ......
用 Java 解密 C# 加密的数据(DES)
[原文地址：http://yidinghe.cnblogs.com/articles/449212.html]
今天碰上一件令我头大的事情。我们的系统要和一个外部系统进行通讯，传输方式是采用 DES 算法对消息进行加密，再用 BASE64 编码。不过对方系统是用 C# 写的。平台不一样，于是我和对面的老兄先测试一下加密解密。这一测试问题就来了。两边采用同样的密钥，对同一个字符串加密出来的结果不一样。怎么办呢？我先把他那边的代码要过来了，他是这样写的(C#)：
public static string Encrypt(string message, string key)
{
DES des = new DESCryptoServiceProvider();
des.Key = Encoding.UTF8.GetBytes(key);
des.IV = Encoding.UTF8.GetBytes(key);
byte[] bytes = Encoding.UTF8.GetBytes(message);
&nb ......
用 Java 解密 C# 加密的数据(DES)
[原文地址：http://yidinghe.cnblogs.com/articles/449212.html]
今天碰上一件令我头大的事情。我们的系统要和一个外部系统进行通讯，传输方式是采用 DES 算法对消息进行加密，再用 BASE64 编码。不过对方系统是用 C# 写的。平台不一样，于是我和对面的老兄先测试一下加密解密。这一测试问题就来了。两边采用同样的密钥，对同一个字符串加密出来的结果不一样。怎么办呢？我先把他那边的代码要过来了，他是这样写的(C#)：
public static string Encrypt(string message, string key)
{
DES des = new DESCryptoServiceProvider();
des.Key = Encoding.UTF8.GetBytes(key);
des.IV = Encoding.UTF8.GetBytes(key);
byte[] bytes = Encoding.UTF8.GetBytes(message);
&nb ......
java 与 c# 3des 加解密
主要差异如下：
1、 对于待加密解密的数据，各自的填充模式不一样
C#的模式有：ANSIX923、ISO10126、None、PKCS7、Zero，而Java有：NoPadding、PKCS5Padding、SSL3Padding
2、 各自默认的3DES实现，模式和填充方式不一样
C#的默认模式为CBC,默认填充方式为PKCS7; java的默认模式为ECB，默认填充方式为PKCS5Padding
3、 各自的key的size不一样
C#中key的size为16和24均可；java中要求key的size必须为24；对于CBC模式下的向量iv的size两者均要求必须为8
翻看了3DES的原理：
DES主要采用替换和移位的方法,用56位密钥对64位二进制数据块进行加密,每次加密可对64位的输入数据进行16轮编码,
经一系列替换和移位后,输入的64位转换成安全不同的64的输出数据
.
3DES:是在DES的基础上采用三重DES,即用两个56位的密钥K1,K2,发送方用K1加密,K2解密,再使用K1加密.接收方使用K1解密,K2加密,再使用K1解密,
其效果相当于密钥长度加倍.
于是尝试在java中，对key进行补位，即用前8个字节作为byte[24] 中的byte[16]~byte[23];发现与c#中加密的结果相同！于是大胆假设C#中可能是检查key的size为16的时候
自动将前8个字节作为k3进行了补 ......
java 与 c# 3des 加解密
主要差异如下：
1、 对于待加密解密的数据，各自的填充模式不一样
C#的模式有：ANSIX923、ISO10126、None、PKCS7、Zero，而Java有：NoPadding、PKCS5Padding、SSL3Padding
2、 各自默认的3DES实现，模式和填充方式不一样
C#的默认模式为CBC,默认填充方式为PKCS7; java的默认模式为ECB，默认填充方式为PKCS5Padding
3、 各自的key的size不一样
C#中key的size为16和24均可；java中要求key的size必须为24；对于CBC模式下的向量iv的size两者均要求必须为8
翻看了3DES的原理：
DES主要采用替换和移位的方法,用56位密钥对64位二进制数据块进行加密,每次加密可对64位的输入数据进行16轮编码,
经一系列替换和移位后,输入的64位转换成安全不同的64的输出数据
.
3DES:是在DES的基础上采用三重DES,即用两个56位的密钥K1,K2,发送方用K1加密,K2解密,再使用K1加密.接收方使用K1解密,K2加密,再使用K1解密,
其效果相当于密钥长度加倍.
于是尝试在java中，对key进行补位，即用前8个字节作为byte[24] 中的byte[16]~byte[23];发现与c#中加密的结果相同！于是大胆假设C#中可能是检查key的size为16的时候
自动将前8个字节作为k3进行了补 ......
from: http://blog.csdn.net/cool_rain_man/archive/2009/02/16/3895210.aspx
JAVA源码学习网站
1. java2s http://www.java2s.com/
这个网站非常好，分成三大类，分别是Example、Products、 Articles，每个大类下又分别设许多小类，还有搜索功能，这样查找起来非常方便。。比如，如果要学习SWT/JFace，只要把Example下的 SWT JFace Eclipse 研究一下也就可以了。另外，这个网站还有JavaScript DHTML、 C# / C Sharp、 C / ANSI-C、 SQL / MySQL等类。总之，非常好。
2. codeZoo http://www.codezoo.com/
这是O'Reily旗下的，除了Java之外，还有Ruby、Python。
3. Java学习源代码检索系统 http://www.chinaitlab.com/www/school/codesearch/index.html
难得看见国产的，好歹也要支持一下，分类也算清楚。
4. Koders http://www.koders.com/
是个综合查询的网站，不过它好像是从代码中查找关键词，包含的语言挺多的。
5. Resources for Java server-side developers http://www.java201.com/
确切的 ......
最新文章 :