使用JNI发现一个问题，

1. wrong ELF class: ELFCLASS64)
   主要是机器是64位的OS，默认编译的.so是64位

而java设置的默认是32位 JDK， 所以会出现这个问题。
那么就采用编译成32位的.so， 安装 glibc-devel.i686
然后编译指定 -m32 就可以了，

2. 如果执行出现Not found in java.library.path)，这是因为JVM没有找到相应的native library，
   那么就需要设置相应的 path 可以通过

1

java -Djava.library.path='.' HelloWorld

或者

1
2
3

LD_LIBRARY_PATH=`pwd`
export LD_LIBRARY_PATH
Java HelloWorld

这样就搞定了

JNI简单过程：

1
2
3
4
5
6

1）创建一个Java程序，定义原生的c/c++函数
2）javac编译
3）javah -jni声称.h文件
4）创建对应的.c文件，实现对应的.h定义的函数
5）编译.c 生成.so
6) 运行java程序

参考资料：

http://www.cnblogs.com/xiaoxiaoboke/archive/2012/02/13/2349775.html
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniexamp.html#examp
http://blog.csdn.net/mdemonhunter/article/details/6254478

转自： http://blog.sina.com.cn/s/blog_6383597b0100fsiw.html

简单明了的文章，留下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

一．简述javaJVM和跨平台性

	这个问题方的很久的一直没有关系过，常常有人忽略的技术，但是又是相当总要的技术。
作为开始我想先谈谈为什么java会这么强大。主要基于java两个特点：

1）java源程序编译后产生的不是机械码，而是一种和平台太无关的字节码。
   然后通过各个平台的解释器解释执行。
2）java采用泄后联编技术。即对域和内存的管理都是在执行的时候根据需要动态的分配。
   这样就是说java编译产生的字节码才是跨平台的。

二．classLoader的介绍及加载过程

	接下来我们就来说说classLoader，为什么要classLoader呢？与普通程序不同的是，
Java程序（class文件）并不是本地的可执行程序。当运行Java程序时，首先运行JVM（Java虚拟机），然后再把Java
class加载到JVM里头运行，负责加载Java class的这部分就叫做Class Loader。所以 
classLoader的目的在于把class文件装入到jvm中。那么classLoader又在那里的啦？又由谁调用呢？
其实classLoader只是jvm的一个实现的一部分。Jvm提供的一个顶级的classLoader（bootStrap classLoader），
bootStrap classLoader负责加载java核心的API 以满足java程序最基本的需求。Jvm还提供的两个classLoader，
其中Extension ClassLoader负责加载扩展的Java class（例如所有javax.*开头的类和存放在JRE的ext目录下的类），
Application ClassLoader负责加载应用程序自身的类。而Extension ClassLoader和Application ClassLoader 
则由bootStrap classLoader加载。

三．classLoader加载的基本流程
	    
当运行一个程序的时候，JVM启动，运行bootstrap
classloader，该ClassLoader加载java核心API（ExtClassLoader和AppClassLoader也在此时被加载），
然后调用ExtClassLoader加载扩展API，最后AppClassLoader加载CLASSPATH目录下定义的Class，
这就是一个程序最基本的加载流程。

四．classLoader加载的方式
	 
    其实classLoader在加载class文件的时候就采用的双亲委托模式。每一个自定义ClassLoader都必须继承
ClassLoader这个抽象类，而每个ClassLoader都会有一个parent ClassLoader，我们可以看一下ClassLoader这个
抽象类中有一个getParent()方法，这个方法用来返回当前ClassLoader的parent，注意，这个parent不是指的被继承的类，
而是在实例化该ClassLoader时指定的一个ClassLoader，如果这个parent为null，那么就默认该ClassLoader的parent是
bootstrap classloader，这个parent有什么用呢？我们可以考虑这样一种情况，假设我们自定义了一个ClientDefClassLoader，
我们使用这个自定义的ClassLoader加载java.lang.String，那么这里String是否会被这个ClassLoader加载呢？
事实上java.lang.String这个类并不是被这个ClientDefClassLoader加载，而是由bootstrap classloader进行加载，
为什么会这样？实际上这就是双亲委托模式的原因，因为在任何一个自定义ClassLoader加载一个类之前，
它都会先委托它的父亲ClassLoader进行加载，只有当父亲ClassLoader无法加载成功后，才会由自己加载，
在上面这个例子里，因为java.lang.String是属于java核心API的一个类，所以当使用ClientDefClassLoader 
加载它的时候，该ClassLoader会先委托它的父亲ClassLoader进行加载，上面讲过，当ClassLoader的parent为null时，
ClassLoader的parent就是bootstrap

classloader，所以在ClassLoader的最顶层就是bootstrap
classloader，因此最终委托到bootstrap classloader的时候，bootstrap
classloader就会返回String的Class。

五.对于classLoader加载的一些细节说明。
	   
我们来讲解ClassLoader中的两个loadClass方法，都是用来加载class的，但是两者在作用上却有所区别。 

Class loadClass(String name)
Class loadClass(String name, boolean resolve)

我们看到上面两个方法声明，第二个方法的第二个参数是用于设置加载类的时候是否连接该类，true就连接，
否则就不连接。说到连接，不得不在此做一下解释，在JVM加载类的时候，需要经过三个步骤，装载、连接、
初始化。装载就是找到相应的class文件，读入JVM，

初始化就不用说了，最主要就说说连接。连接分三步，
第一步是验证class是否符合规格，
第二步是准备，就是为类变量分配内存同时设置默认初始值，
第三步就是解释，而这步就是可选的，

根据上面loadClass方法的第二个参数来判定是否需要解释，所谓的解释根据《深入JVM》这本书的定义
就是根据类中的符号引用查找相应的实体，再把符号引用替换成一个直接引用的过程。
有点深奥吧，呵呵，在此就不多做解释了，想具体了解就翻翻《深入JVM吧》，呵呵，再这样一步步解释下去，
那就不知道什么时候才能解释得完了。
我们再来看看那个两个参数的loadClass方法，在JAVA API 文档中，该方法的定义是protected，
那也就是说该方法是被保护的，而用户真正应该使用的方法是一个参数的那个，

一个参数的loadclass方法实际上就是调用了两个参数的方法，而第二个参数默认为false，
因此在这里可以看出通过loadClass加载类实际上就是加载的时候并不对该类进行解释，
因此也不会初始化该类。而Class类的forName方法则是相反，使用forName加载的时候就会将Class进行解释和初始化，
forName也有另外一个版本的方法，可以设置是否初始化以及设置ClassLoader，在此就不多讲了。

转自：http://hzy5000.blog.163.com/blog/static/74596452012064452485/

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

1. 第一步安装fcitx

 yum install fcitx.x86_64

2. 设置fcitx为默认输入法
alternatives --config xinputrc
选择fcitx对应的序号

3. 设置启动的环境变量
编辑/etc/profile,在其中加入如下几行
export XMODIFIERS=”@im=fcitx”
export QT_IM_MODULE=fcitx
export GTK_IM_MODULE=fcitx

4. 重启Fedora, 按Ctrl+回车就可以看到fcitx的输入界面了。

X86处理器引入的一个很重要的虚拟化支持就是Non-Root模式和Root模式。VMM运行在Root模式，guest OS都运行在Non-Root模式。

为什么引入这种特殊的模式呢？ 这要从X86的毛病说起，因为X86架构在2005年之前都对虚拟化没有相应的支持：在于，

首先，X86的处理器指令有一部分是特权指令，在用户模式下，它们会被trap，如果在内核模式，不会trap。

除此之外，还有一部分指令很特殊（sensitive instruction），会涉及到对系统资源的访问，比如对标志寄存器的修改。这些指令在用户模式下不会被trap。
这样会造成guest OS 认为状态更改了，但是Hardware本身忽略这些修改。所以需要通过一种手段来截获这些特殊的敏感指令，在VMM层进行相应的模拟，
例如二进制翻译。

虽然在VMware在软件层次的全虚拟化方法性能上不错，但是离开了硬件上的虚拟化支持还是有所打折。2005年——2006年，Intel/AMD推出了VT/SVM，CPU引入了Non-Root模式和Root模式，使得敏感指令在guest OS执行时，会被VMM截获，直接转换等价的硬件指令执行。

KVM最初的出发点就是利用硬件技术的虚拟化，来实现Linux host OS的全虚拟化方案， 而 Vmware直到2007年才推出第一款利用 Hardware虚拟化的 Hypervisor。

参考资料：

KVM: Kernel-based Virtualization Driver
Understanding Full Virtualization, Paravirtualization, and Hardware Assist

Linux下的性能分析工具主要是sysstat工具集：

1） nicstat: 搜集和监控网卡的I/O

1
2
3
4

# ./nicstat.sh -i em1 5
    Time      Int   rKB/s   wKB/s   rPk/s   wPk/s    rAvs    wAvs %Util    Sat
11:36:57      em1   13.05    0.75   11.12    7.44  1202.4   103.2  0.11   0.00
11:37:02      em1    0.11    0.11    1.60    1.60   67.75   70.00  0.00   0.00

下载地址：http://sourceforge.net/projects/nicstat/files/
可以用于分析分布式的java应用程序的网络I/O瓶颈

2）iostat ： 分析硬盘I/O利用率

1
2
3
4

# iostat -xd 5
Linux 3.3.2-6.fc16.x86_64 (localhost.localdomain) 	05/01/2012 	_x86_64_	(4 CPU)
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               1.99     4.42    7.66    3.12   148.28    80.20    42.39     0.33   30.76   12.18   76.45   4.90   5.28

3）vmstat： 分析内存的利用率

1
2
3
4
5

# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0  60692 172812 175668 1690636    0    1    36    20  226   25  3  1 95  1  0	
 si,so 内存的换入换出数据是初步衡量性能的依据

4）vmstat, top 分析CPU的利用率：

1
2
3
4

# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
1  0  64812 166964 176412 1694400    0    1    36    20  226   47  3  1 95  1  0

r 是衡量当前cpu的等待执行的进程队列长度

5）pidstat: 分析潜在进程的竞争resource问题（比如lock）

1
2
3

# pidstat -w -I -p 1231 5
12:03:07 PM       PID   cswch/s nvcswch/s  Command
12:03:12 PM      1231     38.60      0.20  libvirtd

AIX: http://www.ibm.com/developerworks/cn/aix/library/au-aix7optimize1/index.html
Sysstat: http://sebastien.godard.pagesperso-orange.fr/

附注：
如果在64位操作系统，编译nicstat会报类似的错：

1

gnu/stubs-32.h: No such file or directory

方案1： 编译选项改成 -m64
方案2： 安装相关的32位库， 具体参考：

http://docs.redhat.com/docs/en-US/JBoss_Enterprise_SOA_Platform/4.3/html/Getting_Started_Guide/appe-install_jdk_rhel.html#sect-use_alternatives_to_set_default_JDK

如果到灵山游玩选择的是公交出行的话，这篇文章可以给你提供一些帮助信息。

到灵山专线是892路公交车，始发站是苹果园地铁站。由于路程比较长，所以尽量赶最早的班车，如果赶不上7：00的，那就等下一班7：30的。
灵山的这个线路比较有意思，班车会在斋堂站让你下来，你在这里等上山路线的班车，因为892路车要进总站，会在站里停”好”一段时间。我们7：30从苹果园出发，到斋堂接近10：10，然后被莫名其妙的等上山的班车大概1小时。斋堂到双塘涧灵山风景区也接近一个小时路程。

四月份的北京灵山的景区基本可以用一个字形容，秃，听开车的师傅说最好的时候是7，8月份，或者秋季的9月份，那时上山的高原景观会比较有看头。罢了，既来之，则安之。

忘了附上一句:北京灵山风景区站，离灵山山脚很远，约20公里的路程。那里的村民有自己的车专门接待游人，找辆车不是件困难的事情，价钱大概40左右（几个人一起的话，算比较便宜了，想一想中石油的涨价 ～）。

灵山的山脚下有很多村民经营的旅馆，在四月份这个季节，双人间，40元/人，条件就是一般般。

灵山虽然海拔在2303米，但山脚已经1400多米了，而且以高山草原地势为主，所以爬到山顶不会很费事，我们接近1点开始爬，悠闲的爬到山顶大概在4：00左右。

由于安排了两天的行程，比较轻松。当天的晚上在山脚的饭店吃的，一海碗面条+一个炒菜，足够两个人吃的，才34元，烤肉之类的比较贵，我们没点。

第二天早上，赶早车回京。

总结一下：旅馆的住宿条件不怎好，四月份的季节不太适合对高山草原报有很大期望的人。 ：）

以Fedora为例，

1）找到对应对ntp软件包，比如我的OS是64位，那么对应的是ntp.x86_64

1

yum search ntp

2） 安装ntp包

1

sudo yum install ntp.x86_64

3）开始配置ntp的 server：

sudo vim /etc/ntp.conf

1
2
3
4
5
6
7
8

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1 
restrict -6 ::1

# Hosts on local network are less restricted.
restrict 172.16.66.0 mask 255.255.255.0 nomodify notrap

上面这行是允许相关的client机器可以来和server（本机）同步，

server 172.16.15.183

配置局域网里用作NTP服务器的IP，其他的

1
2
3
4

server 0.fedora.pool.ntp.org iburst
server 1.fedora.pool.ntp.org iburst
server 2.fedora.pool.ntp.org iburst
server 3.fedora.pool.ntp.org iburst

根据的机器可以访问公网，可以有选择的注释掉。

4）配置ntp服务机器启动后自动运行，

为了使NTP服务可以在系统引导的时候自动启动，执行：

1

chkconfig ntpd on

启动ntpd：

1
2

service ntpd start

5）检查对应的同步信息，
tail -f /var/log/messages

6) 配置client端，修改 /etc/ntp.conf
加上对应的server ip即可,

1

server 172.16.15.183

同样对client机器执行 4）

7） 使用 ntpstat 来检查同步状态

参考：
http://www.51testing.com/?uid-130600-action-viewspace-itemid-122930
http://www.cyberciti.biz/faq/rhel-fedora-centos-configure-ntp-client-server/

转载： http://apps.hi.baidu.com/share/detail/33864699

用sudo时提示”xxx is not in the sudoers file. This incident will be reported.其中XXX是你的用户名，
也就是你的用户名没有权限使用sudo,我们只要修改一下/etc/sudoers文件就行了。

下面是修改方法

1）进入超级用户模式。也就是输入”su -“,系统会让你输入超级用户密码，输入密码后就进入了超级用户模式。（当然，你也可以直接用root用）
2）添加文件的写权限。也就是输入命令”chmod u+w /etc/sudoers”。
3）编辑/etc/sudoers文件。也就是输入命令”vim /etc/sudoers”,输入”i”进入编辑模式，找到这一 行：”root
ALL=(ALL) ALL”在起下面添加”xxx ALL=(ALL) ALL”(这里的xxx是你的用户名)，然后保存（就是先按一
下Esc键，然后输入”:wq”）退出。
4）撤销文件的写权限。也就是输入命令”chmod u-w /etc/sudoers”。原文档介绍的其他的很多，不再转载，这里仅仅留作记录查看。

转载：http://www.cnblogs.com/tohen/archive/2006/10/26/540216.html

方法一：在场所中的连接中，把该服务器连接删除，重新建一个。
方法二：文件—>设置场所—>编辑当前场所—>连接配置向导，重新配置服务器连接一遍。
方法三：在host文件中加上该服务器IP与服务器名字的解释。(host文件提供的是个静态解析,对与win系统，通常存放在c:\window\system32\drivers\etc里面)

注意：重新登录一次Notes!

我使用了方法2，很简单，ok.

发现一篇文章关于Abstract Class and Interface的问答。很好。

参考地址：

http://interview-questions-java.com/abstract-class-interface.htm