JVM在SUSE下奔溃的原因

      今天同事去厂商部署项目的时候发现项目启动一会便会奔溃，但是项目已经在其他的厂商和自己公司的云服务器上稳定运行了很长时间，且经过了大量严格的功能、并发测试，这让我有些诧异，通过了了解，知道了对方机器的操作系统为SUSE，同事发回了jvm奔溃时生成的hs_err_pid文件。通过查看hs_err_pid文件，发现以下信息较为关键。

Stack: [0x00007f823bcfd000,0x00007f823bdfe000],  sp=0x00007f823bdf7a90,  free space=1002kNative frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)C  [libresolv.so.2+0x7e7d]  __libc_res_nquery+0x4ddC  [libresolv.so.2+0x816d]  __libc_res_nquerydomain+0xcdJava frames: (J=compiled Java code, j=interpreted, Vv=VM code)j  java.net.Inet6AddressImpl.lookupAllHostAddr(Ljava/lang/String;)[Ljava/net/InetAddress;+0j  java.net.InetAddress$1.lookupAllHostAddr(Ljava/lang/String;)[Ljava/net/InetAddress;+4j  java.net.InetAddress.getAddressesFromNameService(Ljava/lang/String;Ljava/net/InetAddress;)[Ljava/net/InetAddress;+51j  java.net.InetAddress.getLocalHost()Ljava/net/InetAddress;+90j  com.mchange.v2.uid.UidUtils.generateVmId()Ljava/lang/String;+30j  com.mchange.v2.uid.UidUtils.<clinit>()V+9v  ~StubRoutines::call_stubj  com.mchange.v2.c3p0.impl.C3P0ImplUtils.<clinit>()V+77v  ~StubRoutines::call_stubj  com.mchange.v2.c3p0.impl.DriverManagerDataSourceBase.<init>(Z)V+69j  com.mchange.v2.c3p0.DriverManagerDataSource.<init>(Z)V+2j  com.mchange.v2.c3p0.DriverManagerDataSource.<init>()V+2j  com.mchange.v2.c3p0.DataSources.unpooledDataSource(Ljava/lang/String;Ljava/util/Properties;)Ljavax/sql/DataSource;+4j  org.hibernate.c3p0.internal.C3P0ConnectionProvider.configure(Ljava/util/Map;)V+414j  org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(Lorg/hibernate/service/spi/ServiceBinding;)V+24j  org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(Lorg/hibernate/service/spi/ServiceBinding;)Lorg/hibernate/service/Service;+55j  org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(Ljava/lang/Class;)Lorg/hibernate/service/Service;+30j  org.hibernate.engine.jdbc.internal.JdbcServicesImpl.buildJdbcConnectionAccess(Ljava/util/Map;)Lorg/hibernate/engine/jdbc/spi/JdbcConnectionAccess;+20j  org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(Ljava/util/Map;)V+2j  org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(Lorg/hibernate/service/spi/ServiceBinding;)V+24j  org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(Lorg/hibernate/service/spi/ServiceBinding;)Lorg/hibernate/service/Service;+55j  org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(Ljava/lang/Class;)Lorg/hibernate/service/Service;+30j  org.hibernate.cfg.Configuration.buildTypeRegistrations(Lorg/hibernate/service/ServiceRegistry;)V+13j  org.hibernate.cfg.Configuration.buildSessionFactory(Lorg/hibernate/service/ServiceRegistry;)Lorg/hibernate/SessionFactory;+17j  com.dear.simpler.db.utils.HibernateUtil.init()V+35j  com.dear.simpler.db.utils.HibernateUtil.<clinit>()V+18v  ~StubRoutines::call_stubj  com.dear.simpler.dao.impl.BaseDaoImpl.getSession()Lorg/hibernate/Session;+0j  com.dear.simpler.dao.impl.BaseDaoImpl.get(Ljava/io/Serializable;)Ljava/lang/Object;+8j  com.dear.simpler.dbrpc.service.SmbDBOperatorImpl.dbcache_getSpLock(Ljava/lang/String;)Lcom/dear/simpler/dbrpc/thrift/Response;+25v  ~StubRoutines::call_stubj  sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0j  sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87j  sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+57j  com.dear.simpler.dbrpc.processor.SMBDBServiceImpl.invokeMethod(Ljava/lang/String;Ljava/lang/String;)Lcom/dear/simpler/dbrpc/thrift/Response;+44j  com.dear.simpler.dbrpc.processor.SMBDBServiceImpl.getService(Lcom/dear/simpler/dbrpc/thrift/Request;)Lcom/dear/simpler/dbrpc/thrift/Response;+228j  com.dear.simpler.dbrpc.thrift.SMBDBService$Processor$getService.getResult(Lcom/dear/simpler/dbrpc/thrift/SMBDBService$Iface;Lcom/dear/simpler/dbrpc/thrift/SMBDBService$getService_args;)Lcom/dear/simpler/dbrpc/thrift/SMBDBService$getService_result;+14j  com.dear.simpler.dbrpc.thrift.SMBDBService$Processor$getService.getResult(Ljava/lang/Object;Lorg/apache/thrift/TBase;)Lorg/apache/thrift/TBase;+9j  org.apache.thrift.ProcessFunction.process(ILorg/apache/thrift/protocol/TProtocol;Lorg/apache/thrift/protocol/TProtocol;Ljava/lang/Object;)V+86j  org.apache.thrift.TBaseProcessor.process(Lorg/apache/thrift/protocol/TProtocol;Lorg/apache/thrift/protocol/TProtocol;)Z+126j  org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke()V+77j  org.apache.thrift.server.Invocation.run()V+4j  java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+95j  java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5j  java.lang.Thread.run()V+11v  ~StubRoutines::call_stub

通过观察，觉得问题应该就出现在java.net.Inet6AddressImpl.lookupAllHostAddr(Ljava/lang/String;)[Ljava/net/InetAddress;+0的地方，于是开始google 这个方法在SUSE中的问题，看看有没有人其他人遇到过。发现了这个有用信息：

The problem is that the method InetAddress.getLocalHost() does not work in SUSE environment for due to following reason. Wso2ESB uses this method.SUSE ignores the /etc/resolv.conf but only looks at the /etc/hosts file (where you hadn't specified anything besides localhost)http://stackoverflow.com/questions/1881546/inetaddress-getlocalhost-throws-unknownhostexception

原来，Java的InetAddressImpl的getLocalHostName的方法是native的，是本地系统的一个实现。它是依赖系统库来完成主机名，在大多数的linux系统中，都是以/etc/hosts中的配置来查找主机的，但在suse中却用/etc/hosts文件中的配置做主机名，所以会出现问题。

解决方案：在/etc/hosts中加入ip名与主机名的映射即可。问题解决