概述
java的泛型是在java1.5才引入的，也就是说不是天生的，是后天加入的，为了兼容之前的代码，java采用了一种擦除的方式实现了泛型。也就是因为擦除的原因，所以java的泛型使用起来很别扭。

本来泛型的出现，是为了让我们的代码更加泛化一些，但是java的泛型不够泛化。

如果是用不变的类型参数T定义了泛型类或者泛型方法，在泛型代码里是不能用泛型参数调用方法的，当然Object的方法除外，类型参数被擦除到了Object，也就是说泛型代码里不知道类型参数代表的具体类型的。也就是说泛化了，可是功能受限了。

这个问题在C++中是不存在的，T可以调用你设计的方法，这个思想有个专业概念是潜在的类型机制（Latent typing）或者结构化的类型机制，还有个更通俗和流程的叫法是鸭子类型机制。

为了解决上面的问题，java中重载了extends关键字，让泛型类型参数extends具体的类或者接口，这样泛型代码中就可以通过类型参数T调用具体类或者接口中方法。但是这么做的话，就让泛化的概念打折扣了，不那么泛化了，传入类型必须是特定类或其子类。有时候，这种情况的话，就没必要使用泛型了，直接用接口就可以了。
泛型从更高的层次来看，其实是实现了类或者方法和其中使用类型的解耦。这就就能做到泛化
擦除
在《Think in java》中一句对擦除的描述：“在泛型代码内部中，无法获得任何有关泛型参数类型的信息”。通过事实证明这个理解是错的，Gson TypeToken的实现就证明的，这句话是错的。

根据目前自己的有限认知，说一下自己的理解：如果是定义泛型类，泛型类中的泛型类型形参数是会被擦除的，擦除到第一边界；但是，如果是在定义的类的时候，父类泛型类传入了实参的话，我们在运行期还是能获取到泛型类型参数的。我们在理解擦除概念的时候，要小心，不是想当然的认为，所有泛型都运行期都消失了。
关于Gson的TypeToken

【Java】java.lang.reflect.Type详解
例子
        List list1 = new ArrayList<String>(){};
        System.out.println(list1.getClass());//匿名类的类型信息
        System.out.println(Arrays.toString(list1.getClass().getTypeParameters()));
        System.out.println(list1.getClass().getSuperclass());//匿名类的父类的类型信息，也就是ArrayList的类型信息
        System.out.println(Arrays.toString(list1.getClass().getSuperclass().getTypeParameters()));
        //匿名类的父类，带泛型信息的类型信息
        Type type = list1.getClass().getGenericSuperclass();
        System.out.println(type);//java.util.ArrayList<java.lang.String>
        System.out.println(type.getTypeName());//java.util.ArrayList<java.lang.String>
        //泛型信息Type是个接口，看看具体实现类是什么
        System.out.println(type.getClass());//class libcore.reflect.ParameterizedTypeImpl
        System.out.println(type.getClass().getClass());//class java.lang.Class
        //ParameterizedType
        /**
         * 说明一下，上面看着有些乱
         * 父类的类型信息，我一直以来都知道是用Class的对象来表示的，也就是说，在运行期，所有类被加载进内存，
         * 都会生成一个Class的对象用来存储类信息，或者说类的类型信息。
         * 现在发现，对于泛型类，是有额外处理的，泛型类的泛型信息被单独存储到了ParameterizedType的对象中，
         * ParameterizedType是个接口，具体实现是ParameterizedTypeImpl。
         *
         * 不过，看java提供的api，只能访问父类的泛型信息，子类好像没办法访问到
         *
         * ParameterizedType和Class都实现了Type接口。
         * 需要说明的是，不管是什么类，加载到内存都需要生成一个Class对象。
         * type.getClass得到的是表示ParameterizedTypeImpl类型的Class对象。
         * type.getClass().getClass()得到的是Class类型的Class对象，也就是说Class类的类型信息也是Class对象表达的
         */


        List<String> list = new LinkedList<>();
        Class<? extends List> clazz = list.getClass();
        
        //获取接口类型信息
        Type[] genericInterfaces = clazz.getGenericInterfaces();
        for (Type genericInterface : genericInterfaces) {
            System.out.println("Generic Interface：" + genericInterface.getTypeName());
        }

        //打印Type的具体类型
        for (Type genericInterface : genericInterfaces)
            System.out.println("Type Class：" + genericInterface.getClass().getName());


类型推断（type inference）
这块知识点还是挺难理解的，java5、7、8支持的程度不一样，这个依赖于编译器的实现程度了。
    static <T extends A> T deal3() {
        return (T) new A();
    }
    E result = deal3();

    //泛型方法
    static <T extends A> T deal2(C<T> c) {
        return (T)new A();
    }
    //E result1 = deal2(new C<B>());
    B result1 = deal2(new C<B>());

//
class A {}
class B extends A {}
class E extends A {}
class C<T extends A> {
    T value;
    T getValue() {
       return value;
    }

    void setValue(T value) {
        this.value = value;
    }
}

看上面的例子，deal3调用的时候，是要类型推断的，通过目标类型（target type）推断出T是E类型。目标是result，属于E类型。

但是即便这样，在编译期也不能解决类型转换的错误ClassCastException。这是因为确实发生了类型转换。
deal2调用是通过传入的参数类型进行类型推断的，通过调用推断出T是B类型，所以deal2的结果赋给E类型的result1，在编译期直接报错。
Java 8 新特性之泛型的类型推导
特殊说明一下：中文表述不够准确，泛型类型这个词被用的很混乱，它有时表示C，因为类其实也可以表示一个类型，有时T也被叫做泛型类型，T其实是表示类型的一个变量。
原生类型和泛型类型
java为了做到向后兼容，泛型类型的变量是可以赋给原生类型变量的，比如List list = new ArrayList();

在实际开发中，也会遇到把原生类型变量赋给泛型类型变量，也是可以正常工作，而且很常见。
    <K, V> Map<K, V> getMap() {
        Map map = new HashMap();
        return map;
    }


    //采用目标类型进行类型推断
    Map<String , Integer> map = this.getMap();

泛型在继承过程中的使用
java泛型，要使用好，还是挺难的，别说会用，有时看懂都费劲。没办法只能多阅读别人的代码，强化自己的认识。在阅读mosby的时候，就对泛型在继承中的使用有了新的认识。

直接看源码分析吧
public abstract class MvpFragment<V extends MvpView, P extends MvpPresenter<V>> extends Fragment
    implements MvpDelegateCallback<V, P>, MvpView {

  protected FragmentMvpDelegate<V, P> mvpDelegate;

  protected P presenter;

  public abstract P createPresenter();

  @NonNull protected FragmentMvpDelegate<V, P> getMvpDelegate() {
    if (mvpDelegate == null) {
      mvpDelegate = new FragmentMvpDelegateImpl<>(this, this, true, true);
    }

    return mvpDelegate;
  }

  @NonNull @Override public P getPresenter() {
    return presenter;
  }

  @Override public void setPresenter(@NonNull P presenter) {
    this.presenter = presenter;
  }

  @NonNull @Override public V getMvpView() {
    return (V) this;
  }

  @Override public void onViewCreated(View view, @Nullable Bundle savedInstanceState) {
    super.onViewCreated(view, savedInstanceState);
    getMvpDelegate().onViewCreated(view, savedInstanceState);
  }

  @Override public void onDestroyView() {
    super.onDestroyView();
    getMvpDelegate().onDestroyView();
  }

........

}

public interface MvpPresenter<V extends MvpView> {
  @UiThread
  void attachView(@NonNull V view);
  @UiThread
  @Deprecated
  void detachView(boolean retainInstance);
  @UiThread
  void detachView();
  @UiThread
  void destroy();
}

public interface MvpDelegateCallback<V extends MvpView, P extends MvpPresenter<V>> {

  @NonNull P createPresenter();

  P getPresenter();

  void setPresenter(P presenter);

  V getMvpView();
}

public interface MvpView {
}

初学泛型，看到MvpFragment的定义是不是头大，好复杂呀！其实，多理解多训练强化还是可以理解的。

MvpFragment实现了泛型接口MvpDelegateCallback，并且继承了泛型类型形参V和P，首先看看V和P在MvpDelegateCallback中的定义，V extends MvpView，P extends MvpPresenter，也就是V是MvpView或者子类就可以，并且这个V是能满足MvpPresenter泛型参数定义的，P要是MvpPresenter或者子类。

编译器会进行检查的，如果V改成extends View，MvpPresenter的V就会报错Type parameter 'V' is not within its bound; should implement 'com.hannesdorfmann.mosby3.mvp.MvpView',也就是说，虽然不知道V到底是啥，但是得满足MvpPresenter泛型参数定义的边界。MvpDelegateCallback定义了V和P的边界。

MvpFragment继承了MvpDelegateCallback的V和P，在MvpFragment中V和P也是需要有边界的，并且只能比MvpDelegateCallback小或相等，要不然编译器检查后会报错。MvpFragment定义了一样的边界，后面会看到小边界的定义。
我们再看看MvpFragment的定义，MvpFragment还实现了MvpView。我一开始看到这样的定义，就很蒙圈。MvpFragment本身是个MvpView，泛型V定义说明MvpFragment里面用到了MvpView，其实如果是这样也没啥，只是V在MvpFragment的使用是getMvpView返回MvpFragment自己。这样做是，MvpView还有子接口的时候，在扩展MvpFragment定义新类的时候，能够知道更精确的MvpView。语言很难描述情况，看下面MvpLceFragment和MvpLceView的定义就明白了。
public abstract class MvpLceFragment<CV extends View, M, V extends MvpLceView<M>, P extends MvpPresenter<V>>
    extends MvpFragment<V, P> implements MvpLceView<M> {

  protected View loadingView;
  protected CV contentView;
  protected TextView errorView;

  @CallSuper @Override public void onViewCreated(View view, @Nullable Bundle savedInstanceState) {
    super.onViewCreated(view, savedInstanceState);

    loadingView = createLoadingView(view);
    contentView = createContentView(view);
    errorView = createErrorView(view);
	....
 
  }

  @Override public void showLoading(boolean pullToRefresh) {

    if (!pullToRefresh) {
      animateLoadingViewIn();
    }

  @Override public void showContent() {
    animateContentViewIn();
  }

  @Override public void showError(Throwable e, boolean pullToRefresh) {

    String errorMsg = getErrorMessage(e, pullToRefresh);

    if (pullToRefresh) {
      showLightError(errorMsg);
    } else {
      errorView.setText(errorMsg);
      animateErrorViewIn();
    }
  }

  @Override public void onDestroyView() {
    super.onDestroyView();
    loadingView = null;
    contentView = null;
    errorView.setOnClickListener(null);
    errorView = null;
  }
}

public interface MvpLceView<M> extends MvpView {
  @UiThread
  void showLoading(boolean pullToRefresh);
  @UiThread
  void showContent();
  @UiThread
  void showError(Throwable e, boolean pullToRefresh);
  @UiThread
  void setData(M data);
  @UiThread
  void loadData(boolean pullToRefresh);
}


在这里先说一个编程技巧，MvpView定义了一个接口，MvpFragment实现了MvpView接口，后来发现MvpView定义的功能不够用，所以又基于MvpView扩展了一个接口MvpLceView，但是又不想破坏MvpFragment的代码，因为被其它地方多次使用，我们可以像MvpLceFragment一样，继承MvpFragment实现MvpLceView接口就好了。
MvpLceView继承MvpView，同时增加了泛型类型定义M。MvpLceFragment继承MvpFragment实现MvpLceView，因为MvpFragment和MvpLceView的泛型都没有实参化，所以在MvpLceFragment中还得列出并定义。M没有边界，什么类型都行；V边界变小了，变成了MvpLceView，这个编译器是可以接受的；P的边界有些变化，V的边界小了，也是能接受的；同时MvpLceFragment还添加了自己的泛型类型参数CV。

我理解，编译器在检查泛型的时候，只要满足边界就行，因为它也只知道边界信息。
下面看看MvpLceFragment是怎么用的
public class CountriesFragment
    extends MvpLceFragment<SwipeRefreshLayout, List<Country>, CountriesView, CountriesPresenter>
    implements CountriesView, SwipeRefreshLayout.OnRefreshListener {
}

public interface CountriesView extends MvpLceView<List<Country>> {
}

public interface CountriesPresenter extends MvpPresenter<CountriesView>{

  void loadCountries(final boolean pullToRefresh);
}

如果你现在想一个东西死都想不出来

不是你笨，不是你注意力不能集中

不要怪自己

不要怨天尤人，不要放弃自己

关键你要想你为什么想不出来

是哪个短板阻止了你

如何避开这个坑

比如我今天在想二分法求旋转数组的最小值的时候

先去理解二分法的步骤

以为自己已经理解了

代码也写了

但结果与正确的代码相差甚远

原因是有一些临界点，终止条件没想清楚

整个流程也就不是很清楚

这样写出来的代码肯定是有问题的

因为步骤都没整明白

当我去理解步骤的时候也是很难去理解

总是不能get到关键点怎么处理

所以，像这种想不清楚太难的情况只能自己去想，

然后再来和答案对比这不是自讨苦吃，迎难而上

是真的理解别人远远比理解自己难

自己以同样的目标效果，想过一次，做过一次再去看答案，你就很容易理解了

自己想办法，完全是走捷径，不是讨苦吃

要不然你想几天都想不出来，可能是真的。

              
      公司不讲诚信，或不景气无发展  


　　@半死不活：面试时说好的薪资，到正式转正就打了折，让人很不舒服。当时我找老板沟通，老板以公司发展情况有变为由，比原来说好的工资低了500元，还希望我能体谅公司的难处。我能体谅公司，但谁能体谅我呢？答应好的工资不兑现，这样的公司呆下去还有什么意思？ 



　　@HR：公司经营不善可以理解，没前景就不是求职者个人能随便说的了，没诚信在很多时候更是公说公有理，婆说婆有理了。虽然很理解人往高处走的心态，但公司总是由小变大的，苹果公司还有三起三落呢。我们现在是小公司，还是希望寻找能与公司共同进退的人。 



　　与其说公司没有发展不如说与自己职业发展不符。同样说的是发展，这样不仅免去了抱怨公司的嫌疑，更能证明你是先从自己入手找原因。你的跳槽理由不单是为自己澄清，更是要传递给新公司信任感和信心。 



      加班没有尽头，工作压力大  


　　@Jennifer：这份工作到现在不满一年，我瘦了五、六斤先不说，就当减肥好了。但是每周四天要加班的工作节奏，太影响我正常生活了。长期吃不到晚饭导致我得了胃炎，周末还常接到公司电话要我处理工作，完全不能放松。说的好听点是能者多劳，但实际上难道不是公司在节约人工成本吗？ 



　　@HR：这个理由原则上不能接受。除非求职者能充分证明公司有压榨劳动力。毕竟，公司如果处于创业初期，还在生存线上苦苦挣扎，加班多、工作量大是正常的。  


　　好工作要有前途又要不加班无压力，这是“鱼和熊掌”的问题。站在个人角度，工作是为了更好地生活；站在公司角度，工作是在创造利益。为了完成目标，工作就一定会有压力。加班是工作量大的表现，如果确认自己的工作效率和能力没有问题，那就像上述HR所言，请充分证明公司有压榨劳动力的嫌疑，不然这个跳槽理由有点危险。 



      长年不加工资  


　　@马上有钱：都说经济基础决定家庭地位，可没想到，工作都快三年了，工资一毛钱都没有涨，就别提什么家庭地位了，头都抬不起来了。每年年末都要和老板谈一次“薪”，甚至动用了跳槽来“威胁”加薪，可是永远得不到满意的回复。似乎我的存在可有可无，而我的跳槽也不会对对他们产生任何影响。既然如此，我还留着干嘛呢？ 



　　@HR：不加薪理由有很多，除去公司的原因。员工是否在自己身上找过原因呢？例如绩效不合格，工作不积极不努力？  

      求职者在面试时抱怨前东家是大忌，这会让面试官觉得你是一个不会自我反省、凡事都在别人身上找问题的人。何不换个思路？与其说公司不给你加薪，倒不如说明你在这两年结婚生子，需要承担家庭责任，现有薪资已无法满足生活基本开销的情况。不是前东家的错，只是生活所迫。  


     上有老下有小，工作家庭难兼顾  


　　@abby：公司到家单程一个半小时，路程真心远，但公司环境还不错，工资不高但也能活，所以就干了几年。结果这一切都随着宝宝的出生而改变了。每天很晚回家还要带孩子，先不说自己下班很累，光是父母亲帮我照看孩子就让我很内疚。有天我下班回家，母亲身上背着个玩具吉他在逗弄宝宝，看到这一情景我就哭了。女儿不孝啊，结婚成家了，母亲一天好日子都没过上，还要为我带娃，我还每天那么晚回家，真心觉得对不住。而且自己与宝宝的亲密时间也减少了，所以我无奈离开了那家公司。 



　　@HR：照顾家庭无可厚非，但并不代表在上班时间也可以无限关心家里。没有哪家公司愿意招一个人在公司，心却在家里的员工。当然重大变故除外。  


　　家庭与工作之间的平衡，永远是个难题，尤其是对于女性。在陈述这个理由时，需要传递的信息是，我爱工作也爱家庭。家庭需要照顾，但工作也不会打折，无需在工作时间对我特殊照顾。（完） 

问题场景：某个用户向你反映说你开发的网站访问速度很慢，但是该用户访问其他问题很正常，分析下原因、有哪些工具分析原因、怎么解决问题？
一、针对这个题目我们可以简单理解成是server端出现的问题，而不是client端出现了问题（用户网络不好包括域名服务器解析等可能），当然面试官要考你用户端的知识，例如域名解析，也是有挺多可以考到的知识点，但单就这个问题，更强调的是server端的知识点。下面逐一来剖析可能的原因：
（1）可能的原因一：服务器出口带宽不够用。这是一个很常见的瓶颈。一方面，可能是本身购买的服务器出口带宽就很小（企业购买带宽相当昂贵），一旦用户访问量上来了，并发量大了，自然均分给用户的出口带宽就更小了，所以某些用户的访问速度就会下降了很多。另一个，就是跨运营商网络导致带宽缩减，例如很多公司的网站（服务器）是放在电信的网络上的，而如果用户这边对接的是长城或者说联通的宽带，运营商之间网络传输在对接时是会有限制的，这就可能导致带宽的缩减。
（2）可能原因二：服务器负载过大忙不过来，比如说CPU和内存消耗完了，这个容易理解，不展开。
（3）可能原因三：网站的开发代码没写好，例如MySQL语句没有进行优化，导致数据库的读写相当耗费时间。
（4）可能原因四：数据库的瓶颈，也是很常见的一个瓶颈，这点跟上面第三个原因可以一起来说。当我们的数据库变得愈发庞大，比如好多G好多T这么大，那对于数据库的读写就会变得相当缓慢了，索引优化固然能提升一些效率，但数据库已经如此庞大的话，如果每次查询都对这么大的数据库进行全局查询，自然会很慢。这个学过数据库的话也是挺容易理解的。
二、针对上面可能的原因，有哪些方法和工具去检测呢：
（1）某个用户反馈网站访问变慢，怎么去定位问题。首先你自己也打开下网站，看是否会出现用户反映的问题，如果你这边访问没问题，那就可能是用户那边的问题了，这块就是要先确定是用户那一方的问题还是自身比如说服务器或者网站的问题。
（2）发现确实是自己服务器或者网站的问题，那么可以利用浏览器的调试功能（一般浏览器都会有），调试网络看看各种数据加载的速度，哪一项消耗了多少时间都可以看到，是哪块数据耗时过多，是图片加载太慢，还是某些数据加载老半天都查不出来。
（3）然后针对服务器的负载情况，可以去查看下服务器硬件（网络带宽、CPU、内存）的消耗状况。带宽方面查看流量监控看是不是已经到了峰值，带宽不够用了，如果是公司自己买服务器搭的网站服务器的话，需要自己搭建监控环境；如果用的是阿里云腾讯云这些的，那这些平台那边会提供各方面的监控比如CPU、带宽等等，在后台就可以看到了。
（4）如果发现硬件资源消耗都不高，都比较充裕，那要去看看是不是程序的问题了。这个可以通过查日志来找，比如PHP日志、Apache日志、mysql日志等等的错误日志，特别如mysql有个慢查询的日志功能，可以看到是不是某条mysql语句特别慢，如果某条语句花的时间太长，那这条语句很有可能有问题。
（5）至于说到的数据库太庞大，这个直接看就看得到了，比如一个表的文件大小变得特别大了。
三、针对上面的这些问题，有哪些解决和优化的办法呢：
（1）出口带宽的问题，这个很简单，加带宽，有钱就多买带宽，很简单。
（2）mysql语句优化，开发人员职责。
（3）数据库太庞大，为了读写速度，进行“拆表”、“拆库”，就是把数据表或者数据库进行拆分。
（4）上面的拆库拆表都是针对数据库实在太庞大才会这样做，一般在此之前会有其他优化方法，比如mysql的主从复制，一台主服务器专门用于写，然后其他从服务器用来读，写完之后会同步更新到其他读的服务器中。例如阿里的双十一活动，都不知道用了多少万台服务器一起在扛着。
（6）还有这几年用得比较多的非关系型数据库，它使用了缓存机制，它把数据缓存到了内存，用户访问数据直接从内存读取，读取速度就比在磁盘中读取快了很多，还有它的一个key-value读取机制，这个听师兄说之后没听懂。
（7）CDN（content-delivery-network：内容分发网络），鸡蛋放在多个篮子里，把数据放在离用户更近的位置（例如网站的一些静态文件比如图片或者js脚本），用户访问时判断IP来源是广州，那就通过智能DNS解析到广州的服务器上，直接从广州的篮子里去获取数据，速度就快了。这里有个静态数据和动态数据的概念，例如图片和一些js文件一般是不变的，那就可以把它们的映像分布到全国各地，加快速度，而一些需要在网站后台动态产生的一些数据，则需要去到网站所在的服务器去产生并得到。这个涉及到两种数据的显示的问题，这就交由浏览器处理了。同时异步加载的技术例如前端的Ajax技术，异步请求数据，可以使这些动态数据延迟加载，这块自己不怎么了解，可能表述不好。前端开发的人员应该更懂一些。
（8）上面都没有说到架构的优化，如果网站扛不住，是不是网站架构已经不能适应了，比如做个小博客把数据库服务器和web服务器都用同一台服务器，那所有负载都在同一台服务器上了。但是访问量上来扛不住了，就得加服务器了，就得在架构上优化了，比如在数据库上做集群，在web服务器上也做集群，比如web服务器集群，在服务器前面加一个负载均衡，负载均衡就是专门负责分发，把用户的请求均匀分布到各个服务器上。