سؤال

أحتاج إلى إنشاء كائن نقل البيانات ، والذي سأستخدمه لتخزين السجلات التي تم استردادها من قاعدة البيانات. في كائن نقل البيانات هذا ، أحتاج إلى إعلان حقل رقمي. لما هو أفضل - int أو عدد صحيح

إذا قمت بتحديد الحقل على أنه عدد صحيح ، فهل سيكون هناك أي تأثير للأداء بسبب نوع "عدد صحيح" إذا كنت سأسترجع أكثر من 2000 سجل من DB!؟

شكرا مقدما.

هل كانت مفيدة؟

المحلول

Integer هو خيار أفضل ، حيث يمكنه التعامل معه null; ؛ إلى عن على int, null قد يصبح 0, ، بصمت ، إذا resultSet.getInt(..) يستخدم. خلاف ذلك ، قد يلقي بعض الاستثناء ، شيء مثل ، "غير قادر على تعيين null إلى خاصية بدائية ".

الأداء لا يقلق سوى القليل هنا.

  • إذا اخترت int, ، سوف تنتهي إضافة رمز معالجة إضافية ؛ وهذا لن يفيدك كثيرًا. لن يكون الرمز الخاص بك نظيفًا ومستقيمًا إلى الأمام ، والكثير من رمز لوحة الغلاية ، ولن تكتسب الأداء.
  • اسمحوا لي أن أوضح ، بالنسبة لقواعد البيانات ، لا يوجد مثل الصفر. في بعض الأحيان تنتهي من الدخول 0, ، أين null كانت مقصودة. تخيل الحالة التي قدم فيها المستخدم نموذجًا ، ولا يوفر أي قيمة int. سوف ينتهي بك الأمر 0 بشكل افتراضي. من المنطقي ، أو يفعل ذلك حقًا ، عندما يكون هذا الحقل not null في قاعدة البيانات.

نصائح أخرى

يجب عليك حقًا اتخاذ قرارك بناءً على ما تحتاجه للكائن الذي يجب القيام به ، بدلاً من تكاليف الأداء. يجب أن يتم اتخاذ قرار استنادًا إلى الأداء ، بمجرد تحديد مشكلة السرعة مع Profiler - جذر كل الشر وكل ذلك.

انظر إلى بعض ميزات كليهما واستخدم ذلك لقرارك ، على سبيل المثال

  • Integer يمكن ان يكون null, int لا تستطيع. هكذا هو int في ال ديسيبل أ Nullable مجال؟
  • هل تحتاج إلى الوصول إلى Integer طرق الفصل؟
  • هل تفعل الحساب؟

أنا شخصياً أختار دائمًا البدائية على الغلاف. لكن هذا مجرد شيء تفضيل ، بدلاً من أن يعتمد على أي ميزة تقنية.

في رأيي ، فإن الاختيار بين الإعلان عن شيء ما أو عدد صحيح ببساطة يعود إلى ما إذا كان NULL قيمة صالحة لذلك أم لا. سوف يعتني Autoboxing (و Autounboxing) بأي مشكلات في التحويل حيث يجب أن يكون الرقم ببساطة نوعًا أو آخر. من غير المرجح أن يكون الأداء (كما تم الإشارة إليه) ملحوظًا في جميع الحالات تقريبًا.

علاوة على ذلك ، يجب أن يكون INT هو الخيار الطبيعي ، ومن المحتمل أن يكون الأكثر أداءً في حالة أن يكون ذلك مشكلة على أي حال. إذا كنت بحاجة إلى أن تكون قادرًا على تخزين الفهود ، فأنت أنت لديك لاستخدام عدد صحيح (وأيضًا التأكد من عدم وجود مراجع خالية غير محصنة تلقائيًا لطريقة تتطلب ببساطة ints لأن هذا سيؤدي إلى وجود nullpointerxception).

Integer أبطأ نظريًا من int, ، ومع ذلك ، يجب أن يكون تأثير الأداء ضئيلًا ما لم تقم بإجراء أرقام. كما أن تحسينات JIT ستقلل من فقدان الأداء.

استخدم الشخص الذي يناسب وضعك بشكل أفضل من حيث النوع البدائي أو المرجعي.

int أسرع 10x من عدد صحيح

نختبر هذا الرمز مع مكتبة أداء JETM

int n;
EtmPoint point1 = etmMonitor.createPoint("test:objects");
for (n = 0; n < 1000000; n++) {
    Integer t = 0;
    t = 10;
    t = 11;
}

point1.collect();
EtmPoint point = etmMonitor.createPoint("test:primitives");
for (n = 0; n < 1000000; n++) {
    int t = 0;
    t = 10;
    t = 11;
}
point.collect();

etmMonitor.render(new SimpleTextRenderer());

والنتائج:
الاختبار: الكائنات 10.184
الاختبار: Primitives 1.151

لإعطائك فكرة ، ستضيف 2000 عدد صحيح حوالي 0.5 مللي ثانية إلى الاستعلام. إذا كان عليك إجراء تسلسل هذه البيانات ، فقد يضيف أكثر قليلاً.

ومع ذلك ، يجب أن يأتي الصواب أولاً. ليس هناك فائدة من أن تكون سريعة للغاية ولكنها خاطئة. عليك أن تفكر في القيم الخالية وكيفية التعامل معها. (ما لم يكن العمود فارغًا) ، يمكنك استخدام integer.min ___ القيمة أو يمكنك استخدام أ طويل الحقل بدلاً من int واستخدم long.min_value لـ NULL. على الرغم من أنه أكبر من Int ، إلا أنه سيظل أصغر مرات وأكثر كفاءة من عدد صحيح.

أعتقد أن ذلك يعتمد من بين أشياء أخرى على ما تستخدمه للوصول إلى قاعدة البيانات. مع JDBC القديم العادي يمكنك القيام به intS ، بينما يمكن أن يحولها ORM بصمت إلى Integers على أي حال. وسيسمح لك عدد صحيح بالتعامل مع خالية.

int يستخدم من قبل Java لمعظم الحسابات. Integer يستخدم في جميع أشكال المجموعات باستثناء المصفوفات البدائية.

باستخدام الكثير من الأعداد الصحيحة المؤقتة مع تجمع جامع القمامة واستخدام وحدة المعالجة المركزية غير القابلة للحياة في الخلفية التي ستؤدي إلى تباطؤ عام في كل شيء. سيؤدي الكثير من المؤسسات التي يتم حذفها في الثانية في الثانية إلى دخول CG في وضع الطوارئ "أحتاج الآن ذاكرة" يمكن أن يتسبب في أكشاك في التطبيقات الحرجة زمن الوصول (أي: الرسومات التفاعلية في الوقت الفعلي أو وحدات تحكم الأجهزة المادية أو الاتصالات)

لذلك بالنسبة لي ، إذا كان لدي الكثير من المكالمات المتداخلة التي لا تفعل الرياضيات ولكن الوصول إلى الكثير من المجموعات مثل استخدام مفاتيح الخرائط التي أستخدمها عدد صحيح لتجنب الكثير من الملاكمة التلقائية عند تمرير الوسائط.

إذا كانت العمليات مكثفة للرياضيات أو تستخدم كعدادات حلقة أو عمليات أخرى موجهة للرياضيات ولم يتم تخزينها في المجموعات (بخلاف المصفوفات البدائية) ، فأنا أستخدم البدائية. الأمر نفسه ينطبق على جميع البدائل الأخرى باستثناء السلسلة وهو كائن كامل.

int لا يمكن إلقاؤها إلى String مع استخدام toString أو (String).

Integer يمكن أن يلقي ل String مع toString أو (String) ويمكنه التعامل مع null.

إذا كنت تريد التحقق من ملف null ثم قيمة Integer هو الأفضل ولكن إذا كنت ترغب في مقارنة عدد صحيح ، فقد يكون INT أفضل. في المثال التالي ، أستخدم Integer C = 1000 و D = 1000 وقارنه إرجاعه خطأ ولكن في حالة أن يعودوا صحيحًا.

public class IntegerCompare {

    public static void main(String[] args) {
        int a = 1000;
        int b = 1000;

        Integer c = 1000;
        Integer d = 1000;

        if (a == b) {
            System.out.println("int Value Equals");

        }
        if (c == d) {
            System.out.println("Integer value Equals");

        } else {

            System.out.println("Integer Value Not Equals");
        }
    }
}

سيناريو واحد لتغطية هو التحقق من الصحة.

تخيل أن لدينا الفصل التالي:

class Foo{
    @Min(value = 10)
    int val;
}

إذا لم يقدم المستخدم قيمة لـ val في الطلب ، سنحصل على سيء NumberFormatException.

إذا int يتم استبداله Integer, ، يمكننا ان نستخدم @NotNull وحل هذه القضية بأمان أكثر.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top