朋友介绍对象加微信后，对方不搭理你的真实原因都在这里面。

现在生活中很多人因为单身而通过相亲来解决个人问题，但是朋友介绍对象加微信后，却不见对方搭理自己，对比感到很是困惑。有朋友和我聊过，说：”相亲对象加了我的微信后，从不主动联系我，甚至我去找她聊天，她也是不冷不热的回一两句，之后就慢慢地不理我了，我也不知道怎么处理这种情况……”

其实，加了相亲对象微信后就没有下文的情况是常有的，在这里，我们为大家分析了经朋友介绍对象后不回微信的三种可能性。



朋友介绍对象加微信后第一种情况：对象并非自己情愿相亲，加微信也是被迫所为。

平时很多人对相亲都不是自己的意愿，觉得自己年龄还没到非要相亲不可的时候，或者目前还没有谈恋爱的打算，想要享受一个人的自由生活。但是由于父母的安排，不断向自己介绍对象，以多交朋友为由，要自己加对方微信，后来，耐不住父母的念叨而加了相亲对象的微信。

但事实上，加微信本就是被逼行为，所以有了微信以后也不可能去找对方聊天，一般采取爱答不理的态度，久而久之，双方也就不再联系了。



朋友介绍对象加微信后第二种情况：不喜欢以相亲的形式来找对象，所以不搭理对方。

虽说现如今社会上的单身男女众多，有些甚至年龄不小了还是孤身一人，找对象这种想法当然也是有的，但是她们不喜欢以相亲的形式来结束单身生活，甚至是排斥这种方式。

在她们看来，通过相亲认识的对象，都是到了年龄而不得不来解决个人问题的人，这样即使相互看对了眼，之后的相处也缺钱激情。觉得这种被安排的相遇的不对的。

有这种想法的她们，理所当然的对相亲对象不上心，甚至敷衍。从不会主动去找对方聊天，更不会对对方有好感，所以当相亲对象来找自己聊天时，也只是三言两语就打发了，只有做到基本的尊重，面子上过的去就可以了，那么识趣的自然也就不会再来找她了。



朋友介绍对象加微信后第三种情况：通过了解后觉得不适合自己，所以就不理你了。

有些人在找对象时，也会认真的对待，会去了解相亲对象的信息，也想真正的找个人相处。她们不排斥相亲，会去加对方的微信，但是，当通过了解发现自己并不喜欢对方，或者觉得两人不合适，认为再接触下去也是浪费时间，就果断放弃，以后就不想再来往了。



通过相亲来找对象，本来就是看缘分的事情，双方加了微信之后，无论对方对你是热情还是冷淡，都应该保持一颗随遇而安的心。倘若相亲对象对你爱答不理，发消息我不回，她可能是觉得你们不适合，没有再继续发展下去的可能，所以就冷淡处理了。

另一半是会陪我们走过平生的人，我们应该保持真心，相信总会一个人在等着你的！

在并不遥远的上个世纪的中国，谈恋爱还被称为“搞对象”，一个土得掉渣的名字，估计90后的同学们都未必听说过这个词。后来不知为什么，也许是西洋化了吧，这个叫法逐渐地淡出了，“对象”也迅速地被“男朋友”、“女朋友”、“恋人”甚至“情人”所替代，谁要是还称自己的恋人为对象，必定会令人“刮目相看”。而到现在为止还在搞对象的，就只剩下一个人群了：程序员。

好吧，我是标题党，你可能被忽悠了，标题中的对象是OOP中的术语Object。但请相信一点，其实这两者也颇有相似之处。

由于雄性荷尔蒙和视觉审美的综合作用，男生们在选择女朋友的时候，基本都希望对方有一个优美的女性曲线，就是一副好身材，那种吃喝无度身材臃肿的女孩儿多半是无法吸引男生的。同理，女生对男生也有类似的心理期待。这应该是人之常情吧。但是，不知为什么，很多程序员在玩OOP的时候，却往往出现相反的选择：搞出一堆臃肿、繁复、冗长、拖沓的对象来。要么是超级巨大的class，有无数个包罗万象的方法，要么是超级冗长的方法，以一当十。为什么同样的一个人在现实世界和程序世界里搞对象的表现却判若两人呢？

虽然我发现了这个现象，但原因还是没能找得到，因此至今仍百思不得其解。有很多次我偶尔回看自己从前写过的一些OO的代码时，会很不解地问自己：为什么把这些不相关的东西统统地放在这个对象里？岂有此理？也看过很多别人的OO代码，也曾频繁的发现类似问题，该有的不该有的全有，该管的不该管的全管，大而全的对象比比皆是。唉。。。

尽管未能发现根源，但是我找到了一个避免的方法：那就是在程序世界里搞对象的时候，也似在现实世界中一样，用挑剔的、审美的眼光去审视每一个类。但凡是发现臃肿之处，绝不姑息，动手术去休整，尽最大努力务必作出一个优美的S曲线来。

最后，想把这个心得体会也共享给同样在OOP世界里搞对象的同仁们，在你设计class的时候，最好把她当成是你程序世界里的女友一样来审视，除了功能以外，务必要秉持美学观点来选择和修整。而且记住，你一定要娶她、和她长相厮守并对她的一生负责到底的。否则，你的随意将使你付出巨大代价，就如同一辈子永远生活在一群丑婆娘中间。

public class TestA {
	private Integer a;
	public Integer getA() {
		return a;
	}
	public void setA(Integer a) {
		this.a = a;
	}
}
public class Test {
	public static void main(String[] args) {
		TestA a = new TestA();
		a.setA(1);
		TestA aa = a;
		a.setA(3);
		System.out.println(aa==a);
		System.out.println(aa.getA());
	}
}

输出结果是true和3，这理解起来很简单，java中对象直接"="赋值其实就是将引用传给对方，让他也指向同一个内存地址。

所以如果a改变了里面属性的值，那这个地址存储的内容就变了，当aa去拿的时候就是变了之后的，因为两个指向依然同一个地址，

所以aa==a是true的。

但如果这么来：
  TestA a = new TestA();
		a.setA(1);
		TestA aa = a;
  a = new TestA();
		a.setA(3);
		System.out.println(aa==a);
		System.out.println(aa.getA());

那输出就是false和1了，因为a又重新new了一个对象，他引用的地址已经变了，就和aa一点关系都没有了！
以上我们都知道，但对于包装类却看似不一样：
public class Test {
	public static void main(String[] args) {
		Integer b = new Integer(5);
		Integer c = b;
		System.out.println(b==c);
		b = b+1;
		System.out.println(b);
		System.out.println(c);
		System.out.println(b==c);
	}
}

以上的运行结果是：

true

6

5

false

这似乎和我们之前的例子不一样了。c和b都指向同一个地址，所以第一次bc是true的，但当b加1之后，c并没有跟着b加1，

bc变成了false，说明两个指向的地址已经不是同一个了。

一开始对这个可能无法理解，我们先看看下面的例子：
public class Test {
	public static void main(String[] args) {
		int x = 1;
		int y = x;
		x = x+1;
		System.out.println(y==x);
	}
}

输出是false，这个我们很容易知道，一开始x和y都是1，当x加1之后，x是2，y还是1，所以yx是false的，数值型的变量在判断时是直接比较他们的值的。
再回忆一下java的装箱和拆箱：

所谓装箱，就是把基本类型用它们相对应的引用类型包起来，使它们可以具有对象的特质，如我们可以把int型包装成Integer类的对象，或者把double包装成Double，等等。

所谓拆箱，就是跟装箱的方向相反，将Integer及Double这样的引用类型的对象重新简化为值类型的数据。

JDK1.5之后可自动进行装箱和拆箱的操作，例子如下：
int i=10;
Integer j=Integer.valueOf(i); //手动装箱操作
int k=j.intValue();//手动拆箱操作

int i1=10
Integer j1=i1;//自动装箱操作
int k1=j1;//自动拆箱操作

通过上面的讲解应该就知道原因了：
	Integer b = new Integer(5);
	Integer c = b;
	System.out.println(b==c);//现在两个指向同一个地址，是true的
	b = b+1;//b是包装类，得拆箱成数值型，然后加1，变成数值6，然后把数值6再装箱变成包装类赋给b，等同于b=Integer.valueOf(b.intValue()+1);
	//Integer.valueOf()会生成一个新的包装类对象(因为valueOf()方法的源码里写着，return的是new Integer()，源码见下)
	System.out.println(b==c);//现在两个指向不同的地址，是false的

终于真相大白了，上面的问题告一段落，我自以为对包装类很懂了，但再看看下面的题目：
    Integer b = 128;
	Integer c = 128;
	System.out.println(b==c);

输出是false，这很好理解，128是数值型的，再赋值给包装类变量时先要装箱，上面的等同于：
     	Integer b = Integer.valueOf(128);
		Integer c = Integer.valueOf(128);
		System.out.println(b==c);

这样很明显可以看成是false的，是两个不同的对象。

再看看这个：
     	Integer b = 100;
		Integer c = 100;
		System.out.println(b==c);

输出居然是true。小学生表示已经崩溃，是不是对java已经无爱了。但是我可不会就这样放弃，到底是什么原因呢？

查看Integer的valueOf方法的源码如下：
public static Integer valueOf(int i) {
final int offset = 128;
if (i >= -128 && i <= 127) { // must cache 
    return IntegerCache.cache[i + offset];
}
    return new Integer(i);
}

于是明白了，在【-128，127】之间的数字，valueOf()返回的是缓存中的对象，所以两次调用返回的是同一个对象。

也就是说Integer(100)这样的对象已经有了一个了，自动装箱之前就不去new了，直接使用缓存里的，所以是同一个对象，指向的是同一个引用地址。

以上代码等同于:
     	Integer b = Integer.valueOf(100);
		Integer c = Integer.valueOf(100);
		System.out.println(b==c);

所以输出是true。

接下来下面这个也很明白了吧：
    Integer a = new Integer(100);  
    Integer b = 100;  
    System.out.println(a == b);

输出的是false，因为a是自己new的对象，不是通过valueOf获取的，没有放进缓存里，所以b在valueOf时还是会new一个

以上代码等同于：
    Integer a = new Integer(100);  
  	Integer b = Integer.valueOf(100);  
    System.out.println(a == b);

这样就看的出来是false了。

总之以上的现象只会在拆装箱，或者你自己手动调用valueOf方法时才会出现！

 

我想所有 Java 程序员都曾被这个 new String 的问题困扰过，这是一道高频的 Java 面试题，但可惜的是网上众说纷纭，竟然找不到标准的答案。有人说创建了 1 个对象，也有人说创建了 2 个对象，还有人说可能创建了 1 个或 2 个对象，但谁都没有拿出干掉对方的证据，这就让我们这帮吃瓜群众们陷入了两难之中，不知道到底该信谁得。

但是今天就斗胆和大家聊聊这个话题，顺便再拿出点证据。

以目前的情况来看，关于 new String("xxx") 创建对象个数的答案有 3 种：

有人说创建了 1 个对象；
	
有人说创建了 2 个对象；
	
有人说创建了 1 个或 2 个对象。
而出现多个答案的关键争议点在「字符串常量池」上，有的说 new 字符串的方式会在常量池创建一个字符串对象，有人说 new 字符串的时候并不会去字符串常量池创建对象，而是在调用 intern() 方法时，才会去字符串常量池检测并创建字符串。

那我们就先来说说这个「字符串常量池」。

 

字符串常量池

字符串的分配和其他的对象分配一样，需要耗费高昂的时间和空间为代价，如果需要大量频繁的创建字符串，会极大程度地影响程序的性能，因此 JVM 为了提高性能和减少内存开销引入了字符串常量池（Constant Pool Table）的概念。

字符串常量池相当于给字符串开辟一个常量池空间类似于缓存区，对于直接赋值的字符串（String s="xxx"）来说，在每次创建字符串时优先使用已经存在字符串常量池的字符串，如果字符串常量池没有相关的字符串，会先在字符串常量池中创建该字符串，然后将引用地址返回变量，如下图所示：

 



 

以上说法可以通过如下代码进行证明：

public class StringExample {
    public static void main(String[] args) {
        String s1 = "Java";
        String s2 = "Java";
        System.out.println(s1 == s2);
    }
}

以上程序的执行结果为：true，说明变量 s1 和变量 s2 指向的是同一个地址。

在这里我们顺便说一下字符串常量池的再不同 JDK 版本的变化。

 

常量池的内存布局

从JDK 1.7 之后把永生代换成的元空间，把字符串常量池从方法区移到了 Java 堆上。

JDK 1.7 内存布局如下图所示：



 

JDK 1.8 内存布局如下图所示：

 



JDK 1.8 与 JDK 1.7 最大的区别是 JDK 1.8 将永久代取消，并设立了元空间。官方给的说明是由于永久代内存经常不够用或发生内存泄露，会爆出 java.lang.OutOfMemoryError: PermGen 的异常，所以把将永久区废弃而改用元空间了，改为了使用本地内存空间，官网解释详情：openjdk.java.net/jeps/122

 

答案解密

认为 new 方式创建了 1 个对象的人认为，new String 只是在堆上创建了一个对象，只有在使用 intern() 时才去常量池中查找并创建字符串。

认为 new 方式创建了 2 个对象的人认为，new String 会在堆上创建一个对象，并且在字符串常量池中也创建一个字符串。

认为 new 方式有可能创建 1 个或 2 个对象的人认为，new String 会先去常量池中判断有没有此字符串，如果有则只在堆上创建一个字符串并且指向常量池中的字符串，如果常量池中没有此字符串，则会创建 2 个对象，先在常量池中新建此字符串，然后把此引用返回给堆上的对象，如下图所示：



 

笔者认为正确的答案：创建 1 个或者 2 个对象。

 

技术论证

解铃还须系铃人，回到问题的那个争议点上，new String 到底会不会在常量池中创建字符呢？我们通过反编译下面这段代码就可以得出正确的结论，代码如下：

public class StringExample {
    public static void main(String[] args) {
        String s1 = new String("javaer-wang");
        String s2 = "wang-javaer";
        String s3 = "wang-javaer";
    }
}

首先我们使用 javac StringExample.java 编译代码，然后我们再使用 javap -v StringExample 查看编译的结果，相关信息如下：

Classfile /Users/admin/github/blog-example/blog-example/src/main/java/com/example/StringExample.class
  Last modified 2020年4月16日; size 401 bytes
  SHA-256 checksum 89833a7365ef2930ac1bc3d7b88dcc5162da4b98996eaac397940d8997c94d8e
  Compiled from "StringExample.java"
public class com.example.StringExample
  minor version: 0
  major version: 58
  flags: (0x0021) ACC_PUBLIC, ACC_SUPER
  this_class: #16                         // com/example/StringExample
  super_class: #2                         // java/lang/Object
  interfaces: 0, fields: 0, methods: 2, attributes: 1
Constant pool:
   #1 = Methodref          #2.#3          // java/lang/Object."<init>":()V
   #2 = Class              #4             // java/lang/Object
   #3 = NameAndType        #5:#6          // "<init>":()V
   #4 = Utf8               java/lang/Object
   #5 = Utf8               <init>
   #6 = Utf8               ()V
   #7 = Class              #8             // java/lang/String
   #8 = Utf8               java/lang/String
   #9 = String             #10            // javaer-wang
  #10 = Utf8               javaer-wang
  #11 = Methodref          #7.#12         // java/lang/String."<init>":(Ljava/lang/String;)V
  #12 = NameAndType        #5:#13         // "<init>":(Ljava/lang/String;)V
  #13 = Utf8               (Ljava/lang/String;)V
  #14 = String             #15            // wang-javaer
  #15 = Utf8               wang-javaer
  #16 = Class              #17            // com/example/StringExample
  #17 = Utf8               com/example/StringExample
  #18 = Utf8               Code
  #19 = Utf8               LineNumberTable
  #20 = Utf8               main
  #21 = Utf8               ([Ljava/lang/String;)V
  #22 = Utf8               SourceFile
  #23 = Utf8               StringExample.java
{
  public com.example.StringExample();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 3: 0

  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=3, locals=4, args_size=1
         0: new           #7                  // class java/lang/String
         3: dup
         4: ldc           #9                  // String javaer-wang
         6: invokespecial #11                 // Method java/lang/String."<init>":(Ljava/lang/String;)V
         9: astore_1
        10: ldc           #14                 // String wang-javaer
        12: astore_2
        13: ldc           #14                 // String wang-javaer
        15: astore_3
        16: return
      LineNumberTable:
        line 5: 0
        line 6: 10
        line 7: 13
        line 8: 16
}
SourceFile: "StringExample.java"


备注：以上代码的运行也编译环境为 jdk1.8.0_101。


其中 Constant pool 表示字符串常量池，我们在字符串编译期的字符串常量池中找到了我们 String s1 = new String("javaer-wang"); 定义的“javaer-wang”字符，在信息 #10 = Utf8 javaer-wang 可以看出，也就是在编译期 new 方式创建的字符串就会被放入到编译期的字符串常量池中，也就是说 new String 的方式会首先去判断字符串常量池，如果没有就会新建字符串那么就会创建 2 个对象，如果已经存在就只会在堆中创建一个对象指向字符串常量池中的字符串。

那么问题来了，以下这段代码的执行结果为 true 还是 false？

String s1 = new String("javaer-wang");
String s2 = new String("javaer-wang");
System.out.println(s1 == s2);

既然 new String 会在常量池中创建字符串，那么执行的结果就应该是 true 了。其实并不是，这里对比的变量 s1 和 s2 堆上地址，因为堆上的地址是不同的，所以结果一定是 false，如下图所示：



 

 

从图中可以看出 s1 和 s2 的引用一定是相同的，而 s3 和 s4 的引用是不同的，对应的程序代码如下：

public static void main(String[] args) {
    String s1 = "Java";
    String s2 = "Java";
    String s3 = new String("Java");
    String s4 = new String("Java");
    System.out.println(s1 == s2);
    System.out.println(s3 == s4);
}

程序执行的结果也符合预期：


true false


 

扩展知识

我们知道 String 是 final 修饰的，也就是说一定被赋值就不能被修改了。但编译器除了有字符串常量池的优化之外，还会对编译期可以确认的字符串进行优化，例如以下代码：

public static void main(String[] args) {
    String s1 = "abc";
    String s2 = "ab" + "c";
    String s3 = "a" + "b" + "c";
    System.out.println(s1 == s2);
    System.out.println(s1 == s3);
}

按照 String 不能被修改的思想来看，s2 应该会在字符串常量池创建两个字符串“ab”和“c”，s3 会创建三个字符串，他们的引用对比结果也一定是 false，但其实不是，他们的结果都是 true，这是编译器优化的功劳。

同样我们使用 javac StringExample.java 先编译代码，再使用 javap -c StringExample 命令查看编译的代码如下：

警告: 文件 ./StringExample.class 不包含类 StringExample
Compiled from "StringExample.java"
public class com.example.StringExample {
  public com.example.StringExample();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: ldc           #7                  // String abc
       2: astore_1
       3: ldc           #7                  // String abc
       5: astore_2
       6: ldc           #7                  // String abc
       8: astore_3
       9: getstatic     #9                  // Field java/lang/System.out:Ljava/io/PrintStream;
      12: aload_1
      13: aload_2
      14: if_acmpne     21
      17: iconst_1
      18: goto          22
      21: iconst_0
      22: invokevirtual #15                 // Method java/io/PrintStream.println:(Z)V
      25: getstatic     #9                  // Field java/lang/System.out:Ljava/io/PrintStream;
      28: aload_1
      29: aload_3
      30: if_acmpne     37
      33: iconst_1
      34: goto          38
      37: iconst_0
      38: invokevirtual #15                 // Method java/io/PrintStream.println:(Z)V
      41: return
}

从 Code 3、6 可以看出字符串都被编译器优化成了字符串“abc”了。

 

总结

本文我们通过 javap -v XXX 的方式查看编译的代码发现 new String 首次会在字符串常量池中创建此字符串，那也就是说，通过 new 创建字符串的方式可能会创建 1 个或 2 个对象，如果常量池中已经存在此字符串只会在堆上创建一个变量，并指向字符串常量池中的值，如果字符串常量池中没有相关的字符，会先创建字符串在返回此字符串的引用给堆空间的变量。我们还将了字符串常量池在 JDK 1.7 和 JDK 1.8 的变化以及编译器对确定字符串的优化。