前言
说实话，以前没碰见过必须只获取一次对象供全局使用的地方，或者说多重复实例化获得新的句柄对程序也没什么影响，但是这种习惯是非常很不好的，比如我最近在向hdfs写入文件的时候我希望FileSystem fs这个句柄只获得一次，后面所有的fs操作都用这一个对象就行，因为有kerberos的验证，如果每次操作都需要获取FileSystem fs这个句柄一来浪费验证的时间，二来会多占用一点内存！
代码
package com.bodyproperty.util;

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.security.UserGroupInformation;
import org.springframework.stereotype.Component;
import java.io.IOException;

/**
 * @Auther: kc
 * @Date: 2018/12/19 11:22
 * @Description:
 */
@Component
public class HdfsUtil {
            static FileSystem fs;
            static{
            if (System.getProperty("os.name").toLowerCase().startsWith("win")) {
                // Windows系统
                System.setProperty("java.security.krb5.conf", "C:/Program Files/MIT/Kerberos/krb5.ini");
            } else {
                // linux系统
                System.setProperty("java.security.krb5.conf", "/etc/krb5.conf");
            }
            Configuration conf = new Configuration();
            //这里设置namenode新
            conf.set("fs.defaultFS", "hdfs://test-da-shanghai:8020");
            //需要增加hadoop开启了安全的配置
            conf.setBoolean("hadoop.security.authorization", true);
            //配置安全认证方式为kerberos
            conf.set("hadoop.security.authentication", "kerberos");
            //设置namenode的principal
            conf.set("dfs.namenode.kerberos.principal", "nn/test-da-shanghai@BIGDATA.COM");
            //设置datanode的principal值为“hdfs/_HOST@YOU-REALM.COM”
            conf.set("dfs.datanode.kerberos.principal", "dn/test-da-shanghai@BIGDATA.COM");

            conf.set("dfs.support.append", "true");
            conf.set("dfs.client.block.write.replace-datanode-on-failure.policy", "NEVER");
            conf.set("dfs.client.block.write.replace-datanode-on-failure.enable", "true");

            //通过hadoop security下中的 UserGroupInformation类来实现使用keytab文件登录
            UserGroupInformation.setConfiguration(conf);
            //设置登录的kerberos principal和对应的keytab文件，其中keytab文件需要kdc管理员生成给到开发人员
            try {
                UserGroupInformation.loginUserFromKeytab("xxxx@BIGDATA.COM", "file:/usr/lihong/lihong.keytab");
            } catch (Exception e) {
                System.out.println("身份认证异常： " + e.getMessage());
                e.printStackTrace();
            }
                try {
                    fs = FileSystem.get(conf);
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
    public static  FileSystem getFs() {
                return  fs;
    }

}

其实整个代码中间的验证全部不用看，主要就是我用static代码块将验证的逻辑包围起来，然后fs这个对象就只会生成一次了，每次调用getFs()方法获得的都是同一个fs对象 。

单机下能不能让我们的Java网络应用支持百万连接？
当然可以！但是有很多的工作要做。
操作系统
首先就是要突破操作系统的限制。
在Linux平台上，无论编写客户端程序还是服务端程序，在进行高并发TCP连接处理时，最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是因为系统为每个TCP连接都要创建一个socket句柄，每个socket句柄同时也是一个文件句柄)。
可使用ulimit命令查看系统允许当前用户进程打开的文件数限制：
`$ ulimit -n``1024`
这表示当前用户的每个进程最多允许同时打开1024个文件，这1024个文件中还得除去每个进程必然打开的标准输入，标准输出等等文件，那么剩下的可用于socket连接的文件数就只有大概1010个左右。也就是说缺省情况下，基于Linux的通讯程序最多允许同时1010个TCP并发连接。
对于想支持更高数量的TCP并发连接的通讯处理程序，就必须修改Linux对当前用户的进程同时打开的文件数量。
修改单个进程打开最大文件数限制的最简单的办法就是使用ulimit命令：
$ ulimit –n 1000000
如果系统回显类似于"Operation not permitted"之类的话，说明上述限制修改失败，实际上是因为在中指定的数值超过了Linux系统对该用户打开文件数的软限制或硬限制。因此，就还需要修改Linux系统对用户的关于打开文件数的软限制和硬限制。
软限制(soft limit):是指Linux在当前系统能够承受的范围内进一步限制用户同时打开的文件数；
硬限制(hardlimit):是根据系统硬件资源状况(主要是系统内存)计算出来的系统最多可同时打开的文件数量。
第一步，修改/etc/security/limits.conf文件，在文件中添加如下行：
　　* soft nofile 1000000　　* hard nofile 1000000
'*'号表示修改所有用户的限制；
soft或hard指定要修改软限制还是硬限制；1000000则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后保存文件。
第二步，修改/etc/pam.d/login文件，在文件中添加如下行：
　　session required /lib/security/pam_limits.so 
这是告诉Linux在用户完成系统登录后，应该调用pam_limits.so模块来设置系统对该用户可使用的各种资源数量的最大限制(包括用户可打开的最大文件数限制)，而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值。修改完后保存此文件。
第三步，查看Linux系统级的最大打开文件数限制，使用如下命令：
　　cat /proc/sys/fs/file-max　　12158
这表明这台Linux系统最多允许同时打开(即包含所有用户打开文件数总和)12158个文件，是Linux系统级硬限制，所有用户级的打开文件数限制都不应超过这个数值。通常这个系统级硬限制是Linux系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制，如果没有特殊需要，不应该修改此限制，除非想为用户级打开文件数限制设置超过此限制的值。
如何修改这个系统最大文件描述符的限制呢？修改sysctl.conf文件
vi /etc/sysctl.conf # 在末尾添加 fs.file_max = 1000000 # 立即生效 sysctl -p
JVM层面相关性能优化
当客户端的并发连接数达到数十万或者数百万时,系统一个较小的抖动就会导致很严重的后果,例如服务端的GC导致应用暂停。GC持续几秒，就会导致海量的客户端设备掉线或者消息积压,一旦系统恢复,会有海量的设备接入或者海量的数据发送很可能瞬间就把服务端冲垮。
JVM层面的调优主要涉及GC参数优化,GC参数设置不当会导致频繁GC,甚至OOM异常,对服务端的稳定运行产生重大影响。
1.确定GC优化目标
GC(垃圾收集)有三个主要指标。
(1)吞吐量:是评价GC能力的重要指标,在不考虑GC引起的停顿时间或内存消耗时,吞吐量是GC能支撑应用程序达到的最高性能指标。
(2)延迟:GC能力的最重要指标之一,是由于GC引起的停顿时间,优化目标是缩短延迟时间或完全消除停顿(STW),避免应用程序在运行过程中发生抖动。
(3)内存占用:GC正常时占用的内存量。
JVM GC调优的三个基本原则如下。
(1) Minor go回收原则:每次新生代GC回收尽可能多的内存,减少应用程序发生Full GC的频率。
2)GC内存最大化原则:垃圾收集器能够使用的内存越大,垃圾收集效率越高,应用程序运行也越流畅。但是过大的内存一次 Full GC耗时可能较长,如果能够有效避免FullGC，就需要做精细化调优。
(3)3选2原则:吞吐量、延迟和内存占用不能兼得,无法同时做到吞吐量和暂停时间都最优,需要根据业务场景做选择。对于大多数应用,吞吐量优先,其次是延迟。当然对于时延敏感型的业务,需要调整次序。
2.确定服务端内存占用
在优化GC之前,需要确定应用程序的内存占用大小,以便为应用程序设置合适的内存,提升GC效率。内存占用与活跃数据有关,活跃数据指的是应用程序稳定运行时长时间存活的Java对象。活跃数据的计算方式:通过GC日志采集GC数据,获取应用程序稳定时老年代占用的Java堆大小,以及永久代(元数据区)占用的Java堆大小,两者之和就是活跃数据的内存占用大小。
3.GC优化过程
1、GC数据的采集和研读
2、设置合适的JVM堆大小
3、选择合适的垃圾回收器和回收策略
当然具体如何做，请参考JVM相关知识。而且GC调优会是一个需要多次调整的过程，期间不仅有参数的变化，更重要的是需要调整业务代码。
写在最后，如果觉得本文不错！ 记得转发+关注一下，后续小编会给大家带来更多原创的精彩技术内容。 也欢迎大家在下方留言，说出你的看法~

我有一个由Spring创建的bean.实际的类与Spring驻留在不同的JAR中.该bean被传递了一个路径作为构造函数参数.但是,我在检索文件句柄时遇到困难.该文件位于WEB-INF / classes /中.我已经尝试过基于WEB-INF的相对路径,但是显然这没有用.
XML：
scope="singleton">
/path/to/file
豆角,扁豆：
public class ConfigurationMapper {
public ConfigurationMapper(String resource) {
_map = new HashMap();
String property = null;
BufferedReader reader = null;
try {
FileReader file = new FileReader(resourcePath);
reader = new BufferedReader(file);
while ((property = reader.readLine()) != null) {
if (property.matches("(.+)=(.+)")) {
String[] temp = property.split("(.+)=(.+)");
_map.put(temp[0], temp[1]);
}
}
} catch (Exception ex){
ex.printStackTrace();
} finally {
if (reader != null)
reader.close();
}
}
//other methods to manipulate settings
}
如何在运行时获取rm.properties文件的正确路径并将其传递给Bean？
编辑：添加了构造函数代码.
编辑：我明白了.我将构造函数参数更改为不再采用路径.现在需要一个资源,因此Spring已经找到了我想要加载的资源.

一．概述
定义：虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型。类加载和连接的过程都是在运行期间完成的。
二. 类的加载方式
1)：本地编译好的class中直接加载
2)：网络加载：java.net.URLClassLoader可以加载url指定的类
3)：从jar、zip等等压缩文件加载类，自动解析jar文件找到class文件去加载util类
4)：从java源代码文件动态编译成为class文件
三．类加载的时机
类加载的生命周期：加载(Loading)-->验证(Verification)-->准备(Preparation)-->解析(Resolution)-->初始化(Initialization)-->使用(Using)-->卸载(Unloading)。如下图所示：
虚拟机规范则是严格规定了有且只有四种情况必须立即对类进行初始化(而加载、验证、准备自然需要在此之前开始)：
1) 遇到new 、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行初始化，则需要先触发其初始化。生成这4条指令的最常见的java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段(被final修饰、已在编译器把结果放入常量池的静态字段除外)的时候，以及调用一个类的静态方法的时候。
2) 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
3) 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
4) 当虚拟机启动时，用户需要指定一个要执行的主类(包含main()方法的那个类)，虚拟机会先初始化这个主类。
可见：当满足上述4中条件之一的任何一种情况都会执行类的静态代码块，而除上述4中情况外，则不会对类的初始化(注意加粗的有且只有4个字)。
四. 类加载的过程(7个阶段)
4.1. 加载
a) 加载阶段的工作
i. 通过一个类的全限定名来获取定义此类的二进制字节流。
ii. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
iii. 在java堆中生成一个代表这个类的java.lang.Class对象，做为方法区这些数据的访问入口。
b) 加载阶段完成之后二进制字节流就按照虚拟机所需的格式存储在方区去中。
4.2. 验证 
这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求。
a) 文件格式验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。
b) 元数据验证：对字节码描述的信息进行语义分析，以确保其描述的信息符合java语言规范的要求。
c) 字节码验证：这个阶段的主要工作是进行数据流和控制流的分析。任务是确保被验证类的方法在运行时不会做出危害虚拟机安全的行为。
d) 符号引用验证：这一阶段发生在虚拟机将符号引用转换为直接引用的时候(解析阶段)，主要是对类自身以外的信息进行匹配性的校验。目的是确保解析动作能够正常执行。
4.3. 准备 
准备阶段是正式为变量分配内存并设置初始值，这些内存都将在方法区中进行分配，这里的变量仅包括类标量不包括实例变量。
4.4. 解析 
解析是虚拟机将常量池的符号引用替换为直接引用的过程。
a) 符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任意形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。
b) 直接引用：直接引用可以是直接指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。直接饮用是与内存布局相关的。
c) 类或接口的解析
d) 字段的解析
e) 类方法解析
f) 接口方法解析
4.5. 初始化 
是根据程序员制定的主观计划区初始化变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是执行类构造器()方法的过程。
关注
感谢阅读，如果这篇文章帮助了您，欢迎 点赞 ，收藏，关注，转发 哟。您的帮助是我们前行的动力，我们会提供更多有价值的内容给大家... 谢谢!