Java开发遇到的那些坑

1. Spring (@Component, @Controller, @Service)类成员变量使用@Value等注解不生效，导致调用变量时报错NullPointerException，可能的原因如下
   • @Value作用在静态成员变量上，Spring不会初始化Bean不会注入静态成员变量
   • 当前类必须是通过@Autowire自动注入方式实例化，new ClassName()的方式不会自动注入成员变量
2. 接口返回对象，则对象的静态成员返回的数据为null，故需要在对象中调用的成员不能定义未静态成员
3. 对redis进行hMGet(byte[] key, byte[]... fields)操作，如果key对应数据不存在，则会返回一个不为空的List，List的各字段值为null，需要对这种情况做校验
4. 类中非静态成员变量，如果不在构造函数中初始化，在成员函数中调用报错NullPointerException
5. newFixedThreadPool导致Full GC：使用Executors.newFixedThreadPool(nThreads)构造线程池处理消息，结果由于消息量很大，造成内存消耗过快，频繁FULL GC。原因是当task超过指定值后，都会放入一个无界队列中，最终导致FullGC。解决方案是构造一个阻塞的有容量限制的（比如5000）任务队列，且在队列满的时候执行CalllerRunsPolicy的拒绝策略

   new ThreadPoolExecutor(nThreads, nThreads,
                   30, TimeUnit.MILLISECONDS,
                   new ArrayBlockingQueue<Runnable>(5000),
                   new ThreadPoolExecutor.CallerRunsPolicy());

6. 使用 kafka默认分区策略生产，只发送数据到部分分区：kafka默认分区策略对key试用murmur2算法哈希，然后对分区数取余得到目标分区。例如分区数是10，如果将key范围设置在0-9，并不能按期望将数据均匀写到所有分区，而只能写到部分分区。想要均匀写到所有分区，需要让key=null，或正将key取值范围设置的足够大(0-long.max)。
7. 消费kafka服务跑一段时间后开始频繁rebalance：查找一段时间问题发现是因为服务频繁full gc导致coordinator检测服务超时(由max.timeout.ms参数决定)。jstat -gc 【pid】查看gc情况 ， jmap -histo 【pid】查看发现有600W+的LinkedBlockingQueue$Node,也就是说LinkedBlockingQueue缓存了太多数据，由下图可知LinkedBlockingQueue的无参构造函数是一个无界队列，所以要试用有参构造函数限制节点数量。
8. 使用BufferedWriter写文件，文件的内容比实际的要少：没有调用BufferedWriter中的flush方法！！！