qa

1、进程、线程
进程：
windows每次启动一个应用就会启动一个进程，jvm就是个进程，tomcat启动后会启动jvm
虚拟机，这是一个进程，此进程中的变量共享
线程：
进程中最小的执行单元，c可以操作进程，创建进程等，jvm无法操作进程，只能操作线程，
每个进程中可以跑多个线程，多线程执行任务，效率高，每个线程做自己的事情，当线程同
时处理共享资源时，会涉及到线程安全问题，就涉及到锁的概念。
2、错误一：启动thrift接口后，用一个test方法去测试，获取thrift中常量方法中的静态变量。
     误以为是同一静态变量，test改变常量的值，thrift就能取到，殊不知，test和thrift是两个
     进程，test和thrift获取的同一静态变量是存到两个进程的两个静态块中，不能共用。
     那为什么用client调用thrift后，改变静态变量后，thrift就会生效呢？
     是因为client端调用的是thrift提供的接口，是用tcp协议提供的接口，实现了线程间的通信，
     用test测试的时候，直接调用的是thrift应用源码的方法，实际是创建了另一个进程。
3、 OpenSSL is not properly installed on your system.
./configure时老是报！
checking openssl/ssl.h usability... no
checking openssl/ssl.h presence... no
checking for openssl/ssl.h... no
configure: error:
  !!! OpenSSL is not properly installed on your system. !!!
  !!! Can not include OpenSSL headers files. 

解决：
yum install -y openssl openssl-devel

4、java.net.SocketException: Too many open files 问题的解决办法

linux 上tomcat 服务器抛出socket异常“文件打开太多”的问题 
java.net.SocketException: Too many open files
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:60)
at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:407)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:70)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
原本以为是tomcat的配置或是应用本身的问题，"谷歌"一把后才发现，该问题的根本原因是由于系统文件资源的限制导致的。

具体可以参考 http://www.bea.com.cn/support_pattern/Too_Many_Open_Files_Pattern.html
的说明。具体的解决方式可以参考一下：
1。ulimit -a 查看系统目前资源限制的设定。
   [ root@test security]# umlimit -a 
-bash: umlimit: command not found
[ root@test security]# ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 7168
virtual memory        (kbytes, -v) unlimited
[ root@test security]# 
通过以上命令，我们可以看到open files 的最大数为1024
那么我们可以通过一下命令修改该参数的最大值
2. ulimit -n 4096
[ root@test security]# ulimit -n 4096
[ root@test security]# ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 4096
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 7168
virtual memory        (kbytes, -v) unlimited

这样我们就修改了系统在同一时间打开文件资源的最大数，基本解决以上问题。

以上部分是查找网络上的解决方法。设置了之后段时间内有作用。


后来仔细想来，问题还是要从根本上解决，于是把以前的代码由认真地看了一遍。终于找到了，罪魁祸首。

在读取文件时，有一些使用的BufferedReader 没有关闭。导致文件一直处于打开状态。造成资源的严重浪费。

修改之后的简单代码如下：

public void test(){
    BufferedReader reader =null;
    try{
        reader = 读取文件;
        String line = "";
        while( ( ine=reader.readLine())!=null){
           其他操作
        }

    } catch (IOException e){
        System.out.println(e);
    } finally{  
         if(reader !=null){
                try {
                    reader.close();
                } catch (IOException e) {
                      e.printStackTrace();
                }
          }
    }

}