作为你们忠实的用户,偶然看了下你们java版本SDK源码···· 惨不忍睹
你们作为一个SDK大数据服务提供商,必然是一个高负载的服务器,那么高性能是必然要做的,
用户的程序中引入你们的SDK你们肯定有责任保证代码的效率。
一。GC垃圾问题
TDAnalytics.java中add()方法没必要用三个new HashMap()来做属性,直接封装一个ThreadLocal的bean不就可以了么,反正上下文立马就打印了。
二。性能问题
TDLoggerConsumer.java 中add()方法为什么要 synchronized???你在synchronized方法中去做序列化?
既然都synchronized了,messageBuffer为什么用StringBuffer这种并发结构?不知道StringBuffer.append()也是synchronized()?
要是担心flush()被调用(很少有人主动这么调用),你可以加一个 重入锁啊,只锁 StringBuffer的操作就行了啊···
综上所述,还是希望你们找个明白人来优化一下。这么大的用户量,日志服务器写的这么差,让人不得不怀疑你们的技术含量啊····
作为你们忠实的用户,偶然看了下你们java版本SDK源码···· 惨不忍睹
你们作为一个SDK大数据服务提供商,必然是一个高负载的服务器,那么高性能是必然要做的,
用户的程序中引入你们的SDK你们肯定有责任保证代码的效率。
一。GC垃圾问题
TDAnalytics.java中add()方法没必要用三个new HashMap()来做属性,直接封装一个ThreadLocal的bean不就可以了么,反正上下文立马就打印了。
二。性能问题
TDLoggerConsumer.java 中add()方法为什么要 synchronized???你在synchronized方法中去做序列化?
既然都synchronized了,messageBuffer为什么用StringBuffer这种并发结构?不知道StringBuffer.append()也是synchronized()?
要是担心flush()被调用(很少有人主动这么调用),你可以加一个 重入锁啊,只锁 StringBuffer的操作就行了啊···
综上所述,还是希望你们找个明白人来优化一下。这么大的用户量,日志服务器写的这么差,让人不得不怀疑你们的技术含量啊····